Re: LuaJIT2 bug: 'mytable[mystring] or 0' wrongly 0

[Daniel Stephens <daniel@...>]

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).

Daniel.

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
>     
>     tbl[1]=10
>
> 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?
>
>