lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 2017-10-15 04:00 PM, Dirk Laurie wrote:

I suppose you mean luaH_getint which is where the switch sends you for
an integer key.

Read carefully.

There are two lines that check whether the index is in the range of
the array part. Only if it is not in there does control flow reach a
hash computation.
And thus I need very large array parts if my input is in that very large range, like 256 instead of 128 for chars in arbitrary strings (I only do things with the lower 128). Why not just skip hash if it's empty? 



2017-10-15 19:05 GMT+02:00 Soni L. <fakedme@gmail.com>:


On 2017-10-15 02:58 PM, Dirk Laurie wrote:

2017-10-15 17:43 GMT+02:00 Soni L. <fakedme@gmail.com>:

I'm reading the Lua code, and it seems that Lua always checks the hash
part,
even for tables that don't use it. Why is this?

That's not how I read the code. Here are the comments and return
statements of luaH_next.

    /* find original element */
    /* try first array part */
    /* a non-nil value? */
   ...
        return 1;
      }
    /* hash part */
    /* a non-nil value? */
   ...
        return 1;
...
    return 0;  /* no more elements */

It's quite possible to return without reaching the code dealing with
the hash part.


Look at luaH_get. e.g. t[1] always checks hash part which does have a cost.
the only way to avoid that cost is to fill the array part: if you have 256
possible values, you need to fill t[1] to t[256]. and ofc t[0] always goes
to the hash part so you also need to shift by one if 0 is a valid index.


--
Disclaimer: these emails may be made public at any given time, with or
without reason. If you don't agree with this, DO NOT REPLY.




--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.