[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Any thoughts on indexing ...?
- From: Mike Pall <mikelu-0804@...>
- Date: Wed, 9 Apr 2008 14:47:14 +0200
Alex Davies wrote:
> And would of course be orders of magnitude faster for large varargs.
Well, yes. But large varargs are rare. Comparison here:
http://lua-users.org/lists/lua-l/2006-04/msg00120.html
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.
--Mike