Re: using array nature for microoptimization

[RLake@...]

> 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)