[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: 51w5 table resize regressions
- From: Mike Pall <mikelu-0503@...>
- Date: Mon, 7 Mar 2005 14:34:18 +0100
Roberto Ierusalimschy wrote:
> > Unfortunately this means that e.g. the object instantiation benchmark
> > from the shootout tests (objinst.lua) is 22% slower. [...] Tracing
> > reveals that 51w4 does many 2->4 resizes of the hash part and 51w5
> > does many 1->2->4 resizes in this particular test.
> This is strange. Doesn't that code use contructors to create the tables?
> Constructors should create the table with the right size, so there
> should be no resizes at all.
Yes, but it uses inheritance, too. The constructor for the parent object
is sized right with 51w5. But the child adds a few elements and this implies
resizing. IMHO this is a pretty common thing in OO inheritance.
Add a printf to setnodevector and you'll see what is happening.
If there was a language construct or a library call that would allow access
to the full lua_createtable() C API, the parent should probably use it.
However this implies prior knowledge about the inheritance chain, which is
not always available. And it does not help with automatic resizing in other
But adding table.create(narray, nhash) surely is the most simple solution.
If the language can't guess, let the programmer guess.