[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.0 to 5.1 performance regression?
- From: askok@...
- Date: Mon, 25 Sep 2006 09:39:02 +0300
In fact, could this be changed in the way that  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.
:) keeping my smilecount
On Sun, 24 Sep 2006 19:19:30 -0500
Steve Heller <firstname.lastname@example.org> wrote:
On Mon, 25 Sep 2006 01:26:24 +0200, Mike Pall
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
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
for the free list. Unfortunately this means it's stored
hash part and not the array part of the registry table.
slows down both operations considerably. The equivalent
uses index 1 for the free list (stored in the array
Could this be changed, and if not, why not? That's a big
hit for what sounds like a pretty basic operation.
You could patch lauxlib.c of course (with some care --
FREELIST_REF alone doesn't work). But for performance
use you may be better off rolling your own reference
I suggest to use your own (presized) table, stored in a
or userdata environment or an upvalue. And keep track of
maximum allocation and the free list anchor on the C side
avoid some of the table lookups.