Repository navigation
base: shrink the code FlatHashMapV2 generates - #7853
Merged
Merged
Conversation
🎨 Perfetto UI Builds & Tests
|
LalitMaganti
force-pushed
the
dev/lalitm/fhm-v2-code-size
branch
4 times, most recently
from
October 8, 2026 23:10
a7180ab to
db2a9a3
Compare
safayat-google
approved these changes
Oct 9, 2026
safayat-google
left a comment
Member
There was a problem hiding this comment.
Looks Great!
Just few nits.
FlatHashMapV2 inlined its whole probe loop into every Find() and Insert() call site, costing ~750 bytes of code per insert+find site vs ~150 for FlatHashMapV1, so moving code over to it would have grown binaries. Insert() now inlines only constructing the key and value; finding or claiming the slot is out of line in FindOrPrepareInsert(), compiled once per key type, as is Find(). The state and the operations which don't depend on the key and value types (allocating, growing, probing for a free slot) move to an untemplated FlatHashMapV2Base, defined in flat_hash_map.cc and shared by all maps, and rehashing moves entries straight into their new slots rather than going through Insert(). Lookups now work as in absl: Find(), Erase(), Insert() and operator[] take a Key, which the caller converts to, and only a transparent Hasher enables other (heterogeneous) key types. MurmurHash is now transparent only for string-like keys: it also was for integers, hashing an int looked up in a map keyed by uint32_t as an int, so e.g. a negative one could miss. Each heterogeneous key type also compiled the probing again. For 16 map types with 8 insert+find sites each (x64): 121KB -> 35KB of code, vs 44KB for FlatHashMapV1. Inserts are unchanged; lookups through the out of line Find() are 4-14% slower in microbenchmarks.
LalitMaganti
force-pushed
the
dev/lalitm/fhm-v2-code-size
branch
from
October 9, 2026 16:54
db2a9a3 to
3a26150
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cuts the code FlatHashMapV2 generates per call site to under what
FlatHashMapV1 generates, without slowing down inserts.
Why
FlatHashMapV2 force-inlined its whole probe loop into every
Find()andInsert(): ~750 bytes of code per insert+find call site vs ~150 forFlatHashMapV1. Moving code over to it, which is otherwise faster, would
have grown binaries by hundreds of KB.
Changes
Insert()inlines only constructing the key and value. Finding orclaiming the slot is out of line in
FindOrPrepareInsert(), compiledonce per key type.
Find()is out of line too.types (allocating, growing, probing for a free slot) move to an
untemplated
FlatHashMapV2Base, shared by all maps, defined in thenew
src/base/flat_hash_map.cc.through
Insert().Find(),Erase(),Insert()andoperator[]take aKey, which the caller converts to, and only atransparent Hasher enables other (heterogeneous) key types.
MurmurHashis now transparent only for string-like keys: it also wasfor integers, hashing an
intlooked up in a map keyed byuint32_tas an
int, so e.g. a negative one could miss (in FlatHashMapV1 too).Benchmarks
Code size for 16 map types (x64,
-O3):Speed,
flat_hash_map_benchmarkon Linux x64: inserts are unchanged.Lookups through the out of line
Find()are 4-14% slower than before,still ~1.7x faster than FlatHashMapV1.
Testing
FlatHashMap*andMurmurHash*unit tests, with one test changed toconstruct its
Key(anintis no longer a heterogeneous key for it) andone added for
MurmurHash's transparency. A trace processor build movedonto this (in the follow-up PR) gives the same query results on three
traces.