Re: using array nature for microoptimization

[Jamie Webb <j@...>]

On Friday 12 March 2004 16:49, John Belmonte wrote:
> >  > 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.
>
> Doesn't this suggest that there should be some syntactic sugar for
> "list" literals, such that "n" is set for you at compile time?

It's not at compile time, but what's wrong with:

function array(...)
	return arg
end

a = array(1, 2, 3, 4)

I presume the case where there is a speed issue is far too rare to warrant 
language support.

-- Jamie Webb