lua-users home
lua-l archive

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

In that particular case, it probably will, since the initial tbl would have been initialized with exactly enough space to hold its original contents (Due to the compiler analyzing the initialization code and counting hash-versus-array parts), and so assigning the new member will cause it to be re-allocated (and thusly "optimized").

Last time I adventured into this bit of the lua code, lua will only do such re-balancing when it needs to grow either the hash or array part (I'm not sure if GC plays into this, i.e. whether a table with lots of free space would be re-balanced, I dont /think/ it does, but at the time I was primarily concerned with table creation so GC didn't really factor into it).


Jim Pryor wrote:
On Mon, Nov 16, 2009 at 10:29:10PM -0200, Roberto Ierusalimschy wrote:
BTW: You'll get better performance if you don't fill the rd[]
array backwards. It degrades into a hash table in this case.
That probably also applies to plain Lua.
It degrades into a hash while it is being filled, but when it finishes
I think the result is always a pure array. (I proved this some time
ago, but I am not sure the algorithm is still exactly the same.)

Do you mean if I do this:

    tbl = {[2]=20,[3]=30,[4]=40}
    -- now tbl is all hash

At the last step an array part big enough to hold 4 elements will be
created, and all the pairs formerly in the hash part will be removed
from there and copied over to the array part?