> 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?
