lua-users home
lua-l archive

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


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