struct Parrot_Lexicals; ArrayHash
Leopold Toetsch
scan over the list of lexical names is performed
(s. sub.c:lexicals_get_position()).
A better way would be to provide a list of lexicals plus a name hash,
where hash values are indices into the list.
As such a functionality might be handy is a general PMC class, I think,
best is to generate a new class named ArrayHash or SortedHash or such.
Proposed Synopsis:
set P0["key"], value
list_push(value); hash_put(key => list.elements-1)
set P0["key"; idx], value
list[idx] = value; hash_put(key => idx)
set value, P0["key"] # retrieve by key
set value, P0[idx] # or by index
Comments welcome,
leo
Matt Fowles
Why not just use a hash and ditch the array then?
Matt
Leopold Toetsch
> Leo~
> Why not just use a hash and ditch the array then?
Because $HL may emit code to access lexicals by numeric index.
> Matt
leo
Vladimir Lipskiy
> scan over the list of lexical names is performed
> (s. sub.c:lexicals_get_position()).
>
> A better way would be to provide a list of lexicals plus a name hash,
> where hash values are indices into the list.
What would be a better way depends on a number of elements on a list.
If the number is small I don't think that a hash search + an access of a
list element will beat a list scanning. And if each lexical scope has its
own list (doesn't it?) a usual number of elements on a list won't exceed
10-20, I bet. In my opinion, if that's the case, it doesn't worth a needless
waste of memory.
Leopold Toetsch
>>The current implementation of find_lex (by_name) is suboptimal. A linear
>>scan over the list of lexical names is performed
>>(s. sub.c:lexicals_get_position()).
>>
>>A better way would be to provide a list of lexicals plus a name hash,
>>where hash values are indices into the list.
>>
>
> What would be a better way depends on a number of elements on a list.
> If the number is small I don't think that a hash search + an access of a
> list element will beat a list scanning. And if each lexical scope has its
> own list (doesn't it?) a usual number of elements on a list won't exceed
> 10-20,
I did compare the linear lexical search with a hash access now:
Locating the first lexical is already slower then a hash access. Getting
the 10th lexical is 4 times slower.store_lex takes double the time of
hash_put.
leo