We (ignition) are looking to use base/hashmap (TemplateHashMap), but there
are a couple of things that I want to change/add for efficiency's sake.
Because these changes would have far-reaching effects, I wanted to send out
the proposed changes before trying to upload any CLs.
My proposed changes are:
- Template the value type, so that small types (e.g. ints) can be stored
inline rather than allocated
- Template the key type, for the same reason
- This has some far reaching effects -- e.g. we can't store holes as
nullptr keys anymore, but have to have a separate boolean existence flag.
suggest that we have an Entry class that is templated on the key, and
specialised for pointer-typed keys to treat null keys as holes.
- Template the hash function and remove the hash fields, because passing
in our own hash values is asking for trouble
- Template the equals/matching function, since we'd be having to
template it on the key type anyway, to skip that dereference
- Move the allocator to a field, because passing different allocators
around as parameters is super sketchy
- More precisely, move it to a private base class to take advantage
of the empty base-class optimisation
- Add a function argument to LookupOrInsert which creates the value,
since the Value type is templated and so we can't rely on null values to
mean newly-inserted entries
And maybe, though I'm less convinced about these:
- Return value references directly for Lookup/LookupOrInsert, rather
than Entries, to make Entries non-public
- Add an stl-like iterator interface rather than Start/Next, also to
make Entries non-public
Most of these I could wrap in a particular <Key=void*, Value=void*>
implementation that would fairly closely imitate the original hash map, but
there would (probably?) still be some differences.
v8-dev mailing list
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.