|
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