lua-users home
lua-l archive

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

Alex Davies wrote:
> And would of course be orders of magnitude faster for large varargs.

Well, yes. But large varargs are rare. Comparison here:

I still think apairs() would be a useful addition to Lua (5.2?).

It would be a concise replacement for the mess with select() over
varargs. It's a reappearing topic on the list, so I guess it has
now become a common idiom (I had to write such a loop for a test
case just yesterday).

And apairs() could replace the 'for i,x in pairs{a,b,c} do' idiom,
too. apairs() creates a closure, which is more lightweight than
creating a table plus its array part.

> Back to trying to figure out at what point it's worth saving the varargs to 
> a table over using the quadratic select,
> whilst keeping in mind that future versions of luajit are likely to 
> completely optimise the select away ;).

Yes, this is doable, but I'm not compiling calls to vararg
functions in LuaJIT 2.x (yet).

select(n, ...) with constant n can be reduced to some stack slot
shuffling and generates no code in an assignment-free SSA IR.

But a variant n would force a spill of '...' to the Lua stack
(which wouldn't be necessary if the number of args is known), ties
up a register for the Lua stack pointer, adds a bounds check and
type check and needs another register for the bound itself.

Interestingly this is more or less the same as a C compiler needs
to do to implement <stdarg.h>. TANSTAAFL.