Re: Lua 5.0 to 5.1 performance regression?

[askok@...]

In fact, could this be changed in the way that [0] would 
use array optimization, too.

If it sounds weird, I bet there's many C-origin users that 
would do (or do) 0..N-1 arrays.  And some bindings might 
also choose to do that, for compatibility sake.

Furthermore, I think Lua documentation says people should 
be free to use either 0..N-1, or 1..N, whichever they 
choose.   Negative indices may be hash-based, they're kind 
of exotic anyways.

-asko

:)  keeping my smilecount


On Sun, 24 Sep 2006 19:19:30 -0500
 Steve Heller <steve@steveheller.com> wrote:
> On Mon, 25 Sep 2006 01:26:24 +0200, Mike Pall 
> <mikelu-0609@mike.de>
> wrote:
>
> > Hi,
> >
> > Glenn Maynard wrote:
> > > The attached code (creating and destroying copies of 
> > > references) runs in .42
> > > seconds wall time on 5.0.2 for me, and 1.8 seconds on 
> > > 5.1.
> > >
> > > Just pushing the reference (and popping it) is .05 
> > > (5.0.2) up to .19 (5.1),
> > > which alone is a huge jump.
> > >
> > > Same compiler flags.  Before I spend time trying to 
> > > track this down, does
> > > anyone know what's up?   I'm using references as a 
> > > low-level data type,
> > > and I don't want to see a 4:1 overhead increase.
> >
> > The 5.1 code for luaL_ref/luaL_unref uses index 0 in the 
> > registry
> > for the free list. Unfortunately this means it's stored 
> > in the
> > hash part and not the array part of the registry table. 
> > This
> > slows down both operations considerably. The equivalent 
> > 5.0 code
> > uses index 1 for the free list (stored in the array 
> > part).
>
> Could this be changed, and if not, why not? That's a big 
> performance
> hit for what sounds like a pretty basic operation.
>
> > You could patch lauxlib.c of course (with some care -- 
> > changing
> > FREELIST_REF alone doesn't work). But for performance 
> > sensitive
> > use you may be better off rolling your own reference 
> > management.
> >
> > I suggest to use your own (presized) table, stored in a 
> > function
> > or userdata environment or an upvalue. And keep track of 
> > the
> > maximum allocation and the free list anchor on the C side 
> > to
> > avoid some of the table lookups.
> >
> > Bye,
> >     Mike
>
> Steve