RE: Lua 5.0 Alpha and api_incr_top

["Joshua Jensen" <jjensen@...>]

>Sorry, but I must say I disagree with you here. If there is a problem 
>with the perfomance of lua_getref(), then that should be tackled.

Sure, I agree.  Since Lua 4.0 and 4.1, many things have become slower
(and many things have become faster).  lua_getref() is one of them.  So
is 'for key, value in table' (by quite a bit).  Or lua_getn().  I just
point out issues as I find them.

>And, LUA 5 has the registry, which is very handy to store long-lived
>C data in. I do not know anything about the performance of the
>registry, but maybe the focus should be on improving the registry's
>performance. 

The registry is nothing more than a table, either hashed lookup or
indexed lookup, depending on key.

>LUA is not FORTH. In Lua, like in many other programming 
>languages, the stack is not ment to be a (semi-) permanent 
>storage area, but rather a way to exchange data between functions. 
>You only pop your arguments from the stack. When the function 
>returns, only the results of the function are left on the stack. 
>This is a Good Thing(tm).

You are assuming that Lua is calling the function.  Since I use Lua
primarily for data management, there is only C (or rather, C++) code.  C
code that accesses the data stored in Lua.  There are no arguments.
There are no return values.  The stack is used only for retrieval of
values from Lua and the subsequent storage back into Lua data, if
desired.  Because of the extremely large data set, the stack must be
able to grow into hundreds of entries each session (or possibly more,
depending on data set size).
 
>In languages like C and C++, that type of stack hygene is enforced 
>by the compiler. Lua, probably for performance reasons, does not 
>enforce such a stack hygene, but that doesn't mean that we should 
>abuse the stack for our own "dubious" purposes. 

Let's look at the differences in api_incr_top between Lua 4.0, 4.1, and
5.0.

4.0: #define api_incr_top(L) {if (L->top == L->stack_last)
luaD_checkstack(L, 1); L->top++;}
4.1: #define api_incr_top(L) {if (L->top >= L->stack_last)
luaD_growstack(L, 1); L->top++;}
5.0: #define api_incr_top(L)   (api_check(L, L->top<L->ci->top),
L->top++)

api_check() is #defined to be nothing, by default.

That said, Lua 5.0 has the potential of being a touch faster, but I'd
bet most profilers don't even notice the difference the if() statement
adds, particularly L->top and L->stack_last are on the same cache line
(on Intel architecture anyway).

I really don't feel I am abusing the stack.  Lua is excellent at data
definition.  Why shouldn't it be used to store data?  That being the
case, why complicate the programmer's life forcing him to know which
functions require an extra stack entry and which functions don't?

Josh