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

[Sergey Rozhenko <sergroj@...>]

On Ср 22.06.16 2:47, Philipp Janda wrote:
> Am 21.06.2016 um 21:15 schröbte Patrick Donnelly:
> > 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 ...
It's not just 'select' that has such performance issues. I frequently 
use varargs like this:
local function f(a, ...)
  print(a)  -- do something with it
  return f(...)
end

I'm sure this also results in O(n^2) operations, because each time an 
argument is deleted from stack, it results in shifting the rest of the 
stack.
Best regards,
Sergey "GrayFace" Rozhenko,                 mailto:sergroj@mail.ru