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

[Dirk Laurie <dirk.laurie@...>]

2016-06-22 12:21 GMT+02:00 steve donovan <steve.j.donovan@gmail.com>:
> On Tue, Jun 21, 2016 at 10:47 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
>> First of all: vararg performance is fine. .... Performance of `select` is fine too.
>> Calling it means pushing all of its arguments to the Lua stack -- like for any
>> other function.
>
> I also wonder whether we're going to squeeze much more performance out
> of this lemon, and whether this is in fact an important lemon.

It is unimportant in the sense that whether traversing the vararg
using select is O(n) or O(n²) seldom matters in practice.

It is important in the sense that it is highly instructive to ponder
the issues involved.

I never understood why 'select' returns all of the arguments
past the first few, instead of returning only one, and why there
is no corresponding function for keeping the first so many.

I thought I understood it by imagining '...' to be internally
represented by some structure not exposed at the Lua level,
in which 'select' would simply be the bumping of a pointer.

Now that I know that VARARG actually copies all of ... to
the stack, I think of 'select' as a reluctant sop to those
who had become accustomed to the Lua 5.0 'arg'.
We're not really supposed to use it, we're supposed to
use table.pack(...) if the actual argument list is array-like.

Seen from that point of view, the lemon is again unimportant.
But getting there was not.