lua-users home
lua-l archive

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

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.


:)  keeping my smilecount

On Sun, 24 Sep 2006 19:19:30 -0500
 Steve Heller <> 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 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.