Re: Extending array types in Ravi

[Dibyendu Majumdar <mobile@...>]

On 3 November 2015 at 13:26, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> One of the other enhancements I have been thinking about for a while
>> is to efficiently support aggregate types. Mainly the idea I have been
>> playing around with is to implement such types using tables - but with
>> numeric indices. The reason for using a numeric index is to help
>> generate efficient code. For example a 'get' operation could be
>> inlined thus:
>>
>> if (l_castS2U(key - 1) < t->sizearray)
>>     v = &t->array[key - 1];
>> else
>>     v = luaH_getint(t, key);
>>
>> The problem with numeric indices is readability and error-proneness.
>> [...]
>
> Did you consider an inline expansion of short string keys? You could
> do a loop unrolling of 'luaH_getstr'. (With 2 steps, I believe you
> get a very high percentage of hits.) It is not the same as the
> above expansion for integer keys, but it could be a reasonable
> compromise.
>

No I hadn't considered that - thanks for the idea! If the parser knows
that the variable is a table (static typing can tell it that) - and
the key is a literal short string (which I believe the parser already
knows from the fact that it is a constant) - then yes, it should be
possible to generate inline code for the initial attempt to access the
element - and failing that either try again as you suggest or fallback
on calling the function luaH_getstr().

Another thing that may help is if there was a way to make a table
fixed in keys - i.e. notify that no further key updates are possible.
This could be used by the table library to optimize the hash table so
that all keys require only single access. I understood you are looking
at this for another reason ... optimization of length operations - but
there is probably also a benefit in scenarios such as here.

Regards