Forum > Linux
Improving run speed on Raspberry (clone)
gidesa:
--- Quote from: marcov on November 22, 2024, 04:13:00 pm ---Simple OO overhead is in the nanosecond realm on GHz SBCs CPUs, not in millisecond.
The problem is probably the polling or the way of polling, not the OO overhead.
--- End quote ---
Thank you. Orange Pi Zero has a 1.5 ghz CPU, so OO is not a problem.
gidesa:
--- Quote from: alpine on November 22, 2024, 04:04:11 pm ---I think you should be a bit more specific in your question. The OO itself is nothing more than dragging a hidden parameter (aka Self) and an additional redirection when calling a virtual methods. Shouldn't be a big performance penalty, rather a problem would be the use of managed variables and exceptions handling.
OTOH the word 'style' in your question may refer to the improper in that case practices like RAII and the extensive use of the heap which is quite typical of the OO. But there are a remedies, though.
--- End quote ---
Thank you Alpine.
What are your referring about extensive use of heap?
alpine:
--- Quote ---What are your referring about extensive use of heap?
--- End quote ---
The first thing is that all object instances are in heap in FPC. You must create them before using them. For example the following pattern (RAII) is quite common:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- O := TMyClass.Create; try O.Something; finally O.Free; end; which I would recommend in general. But when it comes to a programs which are required to work continuously for a long periods then adverse heap effects occur over time. It's when you have mixtures of short-lived and long-lived objects that you're most at risk. Another example is the usage of collections/generic containers - also extensively used in OOP. Their buffers are pre-allocated with some small size at the beginning and then tend to only grow by specified amount when filled.
It is not only the OO that can impact the performance/longevity, using Strings or dynamic arrays (managed types) can also have the similar implications since they're also internally reallocated when needed.
But these are common topics for which there are solutions, that's why I asked what do you mean exactly.
BTW markov's point is quite relevant - is the polling really the most suitable way to work with the devices? I'm not familiar with the RPi and it's I2C hardware provisions, neither with the devices polled.
gidesa:
@Alpine thank you, very clear explanation.
That program has no collections, perhaps dynamic arrays, all objects are created only 1 time in initialization, if I well remember. But I will check better.
About communications with devices, someone has interrupts, but not all. But it should request a more complex hardware wiring. I prefer the simple communication on I2C where master calls, and device answer only when called.
VisualLab:
--- Quote from: gidesa on November 22, 2024, 01:21:46 pm ---The cycle should be as fast as possible, in the order of few milliseconds.
--- End quote ---
Some devices operating on the I2C bus may use data transfer delays, called "clock stretching" (which Broadcom chips used in RPi have problems with). This may not apply to your project. But it's always worth checking (e.g. in the datasheets for the IC).
Navigation
[0] Message Index
[#] Next page
[*] Previous page