Am 28.06.2016 um 05:29 schröbte Tim Hill:
[...]
The only good argument I’ve seen for using “n” over a first-class
length (that is, being able to assign to #t) is that space is only
allocated for the length when it’s needed. However, I just ran a
crude benchmark and (on a 64-bit Mac) Lua seems to be allocating 82
bytes of space for an empty table,
That is more than expected. On 64-bit Linux it's 56 bytes for an empty table. See: https://travis-ci.org/siffiejoe/lua-getsize/jobs/135735768
As I said, it was a crude benchmark. However, even at 56 bytes the argument still stands. Assuming an allocator granularity of 16, that 8 byte integer will be free is the size is indeed 56 bytes (since the heap will allocate 64 bytes). so adding 8 bytes per table (for the length) isn’t much, and might
even be free since most heap allocators round allocations up to
multiples of 16 bytes or more these days anyway.
My personal feeling is that we need a first-class explicitly set
length. If this isn’t set for a given table (is nil), then Lua uses
current # behavior, as do things like table.pack().
Mixing `.n` *and* sequence-style `#` will just combine the confusion, ugly corner cases, and undefined behaviors. Functions that take `.n`-style tables should just throw an error if there is no valid `n`.
I agree, and I would prefer to get rid of “.n” asap, but at the same time how much existing code will break?
—Tim
|
