Good question, and one I tried at first. Unfortunately, std::unordered_map<> has some disadvantages, namely re-hashing my hashes (which I profiled and it had a noticeable performance penalty), no support (that I could find) for a LookupOrInsert of a non-default value, and prime-number bin counts rather than power of two, where again I measured a performance penalty with the former.
On Thu, Sep 15, 2016 at 9:31 AM, Jochen Eisinger <joc...@chromium.org> wrote: > 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. > -- -- 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.