Improving run speed on Raspberry (clone)

[gidesa]

Hello,
I have a FPC program on a Raspberry clone, called Orange PI Zero. His OS is Armbian.
Lazarus +FPC are wonderful tools to develop fast programs on SBC computers.
This program cycles continuously polling a series of I2C sensors/devices.
The cycle should be as fast as possible, in the order of few milliseconds.
My question is: could OO style programming slow execution, adding more software layers? Or can the compiler generate code as fast for OO as for procedural style? 
 

[MarkMLl]

I presume you mean a Raspberry /Pi/ clone.

Are you using a background thread to get the data? What API is it using? Are the devices on a single bus? What's the I2C clockspeed? Do the devices mandate any particular pacing? Taking those last three into consideration, can you guarantee that you can actually access the devices fast enough?

MarkMLl

[gidesa]

I presume you mean a Raspberry /Pi/ clone.

Are you using a background thread to get the data? What API is it using? Are the devices on a single bus? What's the I2C clockspeed? Do the devices mandate any particular pacing? Taking those last three into consideration, can you guarantee that you can actually access the devices fast enough?

Yes, it's a Raspberry Pi clone. A good quantity of Raspberry software can run on it.
The program is not a prototype, it's already running and accessing all devices (6) in a loop of 10 milliseconds (in theory, maybe some cycles are executed in longer time). It's  in practice a cooperative scheduler, so every device is accessed at its required pace, setting appropriate cycle numbers. There is one I2C bus, should be at OS default 400 khz. Anyway there is no malfunction, all devices react as expected, then there is no strict reason to modify it.
So my question is for improving performance, not about fixing errors.

[alpine]

Hello,
I have a FPC program on a Raspberry clone, called Orange PI Zero. His OS is Armbian.
Lazarus +FPC are wonderful tools to develop fast programs on SBC computers.
This program cycles continuously polling a series of I2C sensors/devices.
The cycle should be as fast as possible, in the order of few milliseconds.
My question is: could OO style programming slow execution, adding more software layers? Or can the compiler generate code as fast for OO as for procedural style?

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.

[marcov]

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.

[gidesa]

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.

Thank you. Orange Pi Zero has a 1.5 ghz CPU, so OO is not a problem.

[gidesa]

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.

Thank you Alpine.
What are your referring about extensive use of heap?

[alpine]

What are your referring about extensive use of heap?

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  [Select][+][-]

1.   O := TMyClass.Create;
2.   try
3.     O.Something;
4.   finally
5.     O.Free;
6.   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]

The cycle should be as fast as possible, in the order of few milliseconds.

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).

[gidesa]

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).

Thank you, another important information.