would replacing it with std::unordered_map<> gain the same advantages?
On Thu, Sep 15, 2016 at 10:29 AM <lesz...@chromium.org> wrote: > Hi all, > > 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. I 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. > > Comments/questions/rage? > > - Leszek > > -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
