Repository navigation
tp: move trace processor to FlatHashMapV2 - #7854
Draft
LalitMaganti wants to merge 1 commit into
Draft
LalitMaganti wants to merge 1 commit into
LalitMaganti wants to merge 1 commit into
Conversation
LalitMaganti
added this pull request to stack #7855
October 8, 2026 21:42
🎨 Perfetto UI Builds & Tests
|
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 8, 2026 22:26
064be0c to
a4e9be9
Compare
LalitMaganti
marked this pull request as draft
October 8, 2026 22:33
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 8, 2026 22:33
a4e9be9 to
03efd70
Compare
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 8, 2026 22:57
03efd70 to
da8aa6e
Compare
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 8, 2026 23:10
da8aa6e to
45e38e0
Compare
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 9, 2026 16:58
45e38e0 to
44597a1
Compare
FlatHashMapV2 (a Swiss table) is faster than FlatHashMapV1 in our benchmarks for general workloads and now generates less code, so move trace processor's maps over to it, including the StringPool's string index. The FlatHashMap alias, used by the rest of Perfetto, stays on FlatHashMapV1. A few maps stay on FlatHashMapV1, with a comment: those looked up on every event of a trace whose lookups measured slower on FlatHashMapV2 (args dedup, track interning, slice stacks and thread lookups). V2 stores each value next to its key, so large values or a large table of small padded slots cost more cache misses than V1's separate arrays. Load and load+query times vs before, Linux x64 (min of 5 runs): trace_500mb.pftrace (ftrace) -2.3% / -1.1% post_boot_trace.atr -0.8% / -0.5% ui-funcgraph.pftrace 0.0% / -0.4% trace_processor_shell stripped: -67KB.
LalitMaganti
force-pushed
the
dev/lalitm/tp-flat-hash-map-v2
branch
from
October 9, 2026 21:03
44597a1 to
9e20a97
Compare
This branch has not been deployed
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
1 participant
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
Moves trace processor's maps to FlatHashMapV2, except a few hot ones
which measured slower on it. The
FlatHashMapalias, used by the restof Perfetto, stays on FlatHashMapV1.
Why
FlatHashMapV2 (a Swiss table) is faster than FlatHashMapV1 for general
workloads, and after the parent PR generates less code.
Changes
base::FlatHashMapinsrc/trace_processorbecomesbase::FlatHashMapV2, including theStringPool's string index.(
GlobalArgsTracker::arg_row_for_hash_), track interning(
TrackTracker::tracks_), slice stacks (SliceTracker::stacks_) andthread lookups (
ProcessTracker::tids_,live_tid_). They are hit onevery event, and FlatHashMapV2 stores each value next to its key, so
large values or a large table of small padded slots cost more cache
misses than V1's separate arrays. Profiles of a funcgraph trace put
these at a ~6% load-time regression on FlatHashMapV2.
Benchmarks
trace_processor_shell, Linux x64, min of 5 interleaved runs, vs main:trace_500mb.pftrace(ftrace)post_boot_trace.atrui-funcgraph.pftracePeak RSS within 2%. Stripped binary: -67 KB.
Testing
Only benchmarks so far: query results are identical to main on the
three traces above. FlatHashMapV2 iterates in a different order to
FlatHashMapV1, so tests whose output depends on map iteration order may
need updating.