Re: Lua 5.1+ and variable-argument tables

[Edgar Toernig <froese@...>]

Rici Lake wrote:
>
> On 19-Aug-04, at 8:47 PM, Edgar Toernig wrote:
> 
> > IMHO that's the most important point.  If you accept heap allocation
> > during vararg-function invocation you can stick with tables.  The
> > slight performance advantage of your tuple implementation could
> > be nullified by optimizing the appropriate parts of table creation.
> 
> It's not that slight. You might be surprised. Here's a quick 
> pseudo-benchmark;
>
>[...]
>
> In short, for about 6 lines of code changed, a 35% speedup. It's hard 
> to imagine that the ... thing would be faster than the baseline, and 
> presumably the extra copying and stack management would take some time, 
> so we could guess that the alternative is considerably more change to 
> the code base for a 45% speedup. And I still say that tuples have extra 
> uses.

The problem with benchmarks :-)  You're mostly testing GC performance.
Let me show some other numbers: (3rd column is GC-runs)

currying happens within the loop:
 empty heap:
   4args   6.94   1592
    dots   7.03   1592
   tuple  10.19   3496
   table  14.91   5291
 filled heap (with 10000 {a=1} tables):
   4args   8.75     31
    dots   8.88     31
   tuple  13.85     69
   table  21.42    105

currying outside of the loop - only actual varag handling tested:
 empty heap
   4args   2.48      0
    dots   2.62      0
   tuple   5.81   1908
   table  10.57   3703
 filled heap (with 10000 {a=1} tables):
   4args   2.48      0
    dots   2.62      0
   tuple   7.34     37
   table  14.26     73

-- 4args is with 4 fixed arguments (baseline)
-- dots is the new vararg method (the "... hack")
-- tuple is varargs via tuple (upvalues of c-closure)
-- table is varargs via table (with Lua4 tables - no array part)

As you can see, nearly half of the time your test spends in
creating and collecting the curried function (10.19 vs 5.81).

And while the dots are only ~2 times faster than tuples
(2.62 vs 5.81) with a nearly empty heap it gets worse when
the heap gets bigger (2.62 vs 7.34) as the dots version
has no dependency on heap size.

The times for the table version aren't nice.  I guess mostly
because of the old Lua4 tables without an arry part and a
bigger memory footprint which gives more GC cycles.

> Whether an object is constructed on the heap or the stack is not
> a conceptual difference, it is an implementation detail.

Oh, it is a difference.  There is no "..." object.  There's
only a syntax to access the varargs.  You see the difference
in the benchmark above :-)

> > But it's not the tuple that makes it possible to collect
> > multiple return value but the new syntax.
> 
> Fair enough. One could equally well propose the syntax:
> 
>    a, b, {c} = f()
> 
> I would have no objections to that, really.

Hehe, iirc I once suggested:

   a, b, c[] = f()           -- pack into c

   function foo(a, b, c[])   -- define vararg function

   foo(1, 2, c[])            -- unpack c

;-)

Ciao, ET.