Re: Speed of #t

[Axel Kittenberger <axkibe@...>]

Likely I'm a bit naive about this. But couldn't we just define for #
operator to simply return the size of the array part?

Meaning counted from 1 onwards # to defined the the largest numeric
key where t[k] is not nil. t[#t+1] is nil.

So for
t = {1, nil, nil, 2, nil, 3]
#t can currently be either 1 or 4 or 6. In the above definition it must be 1.


On Mon, Dec 13, 2010 at 11:07 AM, Enrico Colombini <erix@erix.it> wrote:
> On 13/12/2010 10.47, Dirk Laurie wrote:
>>
>> Lua 5.2.0 (alpha)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
>>>
>>> a={1,2,nil,4,5,6,nil,8,nil,nil,nil,12,nil,nil,nil}; return #a
>>
>> [0,7]
>> [0,3]
>> [1,3]
>> [2,3]
>> 2
>>>
>>> a={1,2,nil,4,5,6,nil,8}; a[12]=12; return #a
>>
>> 8
>>
>> No binary search at all in the array+hash case!
>
> Interesting, but what I'm specially interested is: given a proper array (no
> holes), does #t access time get worse if I add a hash part to it?
>
> It would seem so from your post, but from a quick test I note no execution
> time difference.
>
> --
>  Enrico
>
>