lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> Growing an object requires copying, which can't be done in constant time. Most CPUs can copy very quickly but it's still an O(n) operation, however efficient you make the memory management.

Even copying is only O(n) for a "larger" number of bytes n. For small n effects memory access, caching, ... (random effects) do have a much bigger effect on execution time than copying a byte more - making it effectively independent from n. The ~32 bytes mentioned before would be "small" from that point of view.

You are definitely right when it comes to operations with large n, like concatenating lengthy strings ... so ... "don't do that " (or measure up to what length you can handle the resulting delay).

To clarify the recommendation: Write an allocator function where you can log the memory usage profile, recording what memory blocks your Lua program is actually using (for me the vast majority of blocks was < ~60 Bytes, in total some hundred blocks of this size, and after initialization it never needed a block with more than some hundred bytes, ... don't remember the exact numbers). Then preallocate ~1000 blocks * ~60 bytes, lock it in memory, and use this preallocated pool in your allocator function (if you use it for just one state, you can even drop mutexes there).

This way, you will not end up with a "general purpose real time Lua", but with a special purpose system ... that cannot handle lengthy strings, but work with numbers in real time.
From my experience, real time systems are always "special purpose" anyway - so this approach might work for you or not, depending on what the system is supposed to do.
Would you mind telling something about the purpose of the real time system and the role of Lua therein?


On Wed, Sep 23, 2020 at 5:32 PM Gé Weijers <ge@weijers.org> wrote:


On Wed, Sep 23, 2020, 06:15 bel <bel2125@gmail.com> wrote:
One key to reach real-time requirements is not to prevent Lua from dynamically allocating the stack (or any other object), but to provide an allocator function capable of providing memory in a fixed time. (Others are fine tuning garbage collection, preloading libraries and replacing/not using the io library after initializing, by the way).

Growing an object requires copying, which can't be done in constant time. Most CPUs can copy very quickly but it's still an O(n) operation, however efficient you make the memory management.

Some operations performed by the garbage collector may also not meet hard realtime requirements. It all depends on how much delay you can handle.