Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Philipp Janda <siffiejoe@...>]

Am 21.06.2016 um 21:15 schröbte Patrick Donnelly:
> > > On Mon, Jun 20, 2016 at 9:04 PM, Roberto Ierusalimschy
> > > <roberto@inf.puc-rio.br <mailto:roberto@inf.puc-rio.br>> wrote:
> > >
> > > > That is not true. 'select' can be quite slow for a large number of
> > > > parameters (where "large" starts in the order of a few dozen). In
> > > > particular, a typical loop in a vararg function using 'select' is quadratic
> > > > with the number of arguments, while creating a table and traversing it is
> > > > linear.
>
> I don't think anyone wants to actively pursue making the
> implementation of how varargs work now any better. The fact is, the
> Lua authors *could* improve vararg performance so that select isn't so
> abysmal but ... you're still using select. i.e. no one wants to spend
> time optimizing for a function that is widely considered a wart on the
> language.

First of all: vararg performance is fine. At least it is better than 
before when Lua would allocate a new table for every vararg call (of a 
Lua function). Performance of `select` is fine too. Calling it means 
pushing all of its arguments to the Lua stack -- like for any other 
function. What *possibly* could be problematic is looping over varargs 
using `select` because it is O(n^2), which will get slow when used on 
*dozens of arguments*. (Btw., when is the last time you used more than 
20 arguments in a function call?) However, even if you find a case where 
this is a problem, there is an alternative (and linear) way to iterate 
varargs at the cost of a table allocation before the loop. Just go where 
your profiler guides you ...


Philipp