Re: Lua 5.0 wasn't that bad, actually

[Tim Hill <drtimhill@...>]

> On Jun 27, 2018, at 10:58 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> Am 27.06.2018 um 10:08 schröbte Tim Hill:
>> — Add an internal “array length” value to each table (very much like the old getn/setn). And no, in most cases this will NOT add memory overhead given the granularity of most help allocators these days.
> 
> I'd say the expected memory overhead for an additional 32bit array length field is 4 bytes. It may fit into the memory block that's allocated anyway (due to granularity), or it may just overflow the block and cause a larger memory overhead (also due to granularity). Without knowing the current table size and the granularity of your memory allocator that's all you can say.
> 
> Now, the current size of an empty table is 56 bytes in Lua 5.3 on amd64. That's a multiple of 8 but not 16, so if the memory allocator's granularity is 16, then a 4 byte (or even 8 byte) array length field is for free. If the granularity is 8 bytes, the array length field will cost 8 bytes.
> 

Understood. On macOS, all 64-bit Linux, and Windows, malloc() currently has 16-byte granularity (the last time I checked, about 18 months ago). Of course, your mileage will vary and in embedded systems (where memory is often at a premium) I would expect a finer granularity. But in such cases I would expect a “reduced” version of Lua anyway (e.g. jettison some libraries).

It’s interesting though, as Dirk notes, that tables USED to have this value in 5.0 and it was later dropped, so in some ways it’s a wash. Adding overhead to tables is to be avoided of course, especially when you have lots of little tables, but that is something of an anti-pattern anyway (as noted in PiL).

—Tim