> Also, if you plan on doing a lot of unpack() calls on prepared tables
> you construct, add an "n=3" to your {"start",
"b", {}, n=3} tables.
> That was good for another 5% speedup....
That is generally true of table-as-vector functions.
If you don't specify n, either as a key or with a call to table.setn(),
the library has to do a complete scan of all keys to find the largest
integer index. This is different from functions (like table.foreachi)
which don't attempt to deal with sparse arrays, and only scan up to the
first nil value.
Note that the varargs semantics add the "n"
key, so if you have
function foo(a1, a2, ...)
then arg will already have an "n" key and
you don't have to worry about it.
(Although I understand that the implementation of
... is due to change in 5.1)