tp: add cold sorts by key for sorts which are not hot

[LalitMaganti]

Summary

Adds ColdSortByKey and ColdStableSortByKey, replacements for std::sort and std::stable_sort which sort by an integer key through one sort compiled once rather than once per call site, and moves the sorts which are not hot over to them. This saves 110KB of trace_processor_shell's code on Linux and 147KB of the Wasm module.

Why

std::sort and std::stable_sort are templates: every element type and comparator gets its own copy, at 3-4KB each. Most of TP's sorts run once per query or once per trace on a handful of elements, where that code buys nothing.

Changes

• util/cold_sort.h: each caller extracts an integer key per element into {key, index} pairs, which one std::sort compiled in cold_sort.cc orders, then moves the elements into place by following the permutation's cycles. Ties break on the index, so the sort is stable; ColdSortByKey and ColdStableSortByKey share it, and the names record whether a caller relies on that. ...Descending variants sort the other way. Up to 64 elements the pairs live on the stack, so small sorts never allocate.
• Moved over: query planning's filter order, the PerfettoSQL parser, SQL rewrites, trace type detection, system probes' CPU info, perf feature sections, CPU per UID, the ninja log, the symbolizer's report, metatrace args, SurfaceFlinger layer order, interval intersect's operand order, JSON export's async end events, Android logs and the memory graph's owners.
  • Perf feature sections (offset, then size, both descending) and memory graph owners (priority descending, then size) are two passes, the second stable.
  • SurfaceFlinger's (z, id) is packed into one 64-bit key.
• Hot sorts stay on std::sort: the executor and interpreter, the dataframe sort, the trace sorter, interval intersect's interval sort, the flamegraph, slice layout and heap graphs.

Example

// Before: a copy of std::sort for this lambda.
std::sort(items.begin(), items.end(), [](const Item& a, const Item& b) {
  return a.offset < b.offset;
});
// After: a key extraction calling the shared sort.
ColdSortByKey(items.begin(), items.end(),
              [](const Item& item) { return item.offset; });

Benchmarks

Size, release builds:

	Before	After
trace_processor_shell .text, Linux x86-64	9,434,514 bytes	9,324,850 bytes (-109,664, -1.16%)
trace_processor.wasm	14,235,488 bytes	14,088,363 bytes (-147,125, -1.03%)

Per call site, one {int64, uint32} sort by a lambda at -O2 on x86-64:

	Code
std::sort	4.4 KB
std::stable_sort	2.8 KB
ColdSortByKey	0.45 KB, plus 4 KB shared once

Speed on Linux x86-64, sorting by an int64 field:

Elements	12-byte elements: std::sort / by key	64-byte elements: std::sort / by key
3	4.8 / 10 ns	6.5 / 12 ns
16	39 / 76 ns	70 / 82 ns
1,000	5.2 / 10.4 us	10.0 / 12.4 us
100,000	5.2 / 7.4 ms	5.5 / 7.2 ms

Mocks of each moved call site, with its element type, key and comparator, show the sorts whose comparators did lookups or copies getting faster: JSON export 6-9x, CPU infos 7-20x, SurfaceFlinger 2.6-4x, trace type detection and the symbolizer 2.3x. The largest slowdown is Android logs, 1.7ms per 100k lines.

Testing

New ColdSortTests check against std::stable_sort across sizes, including both sides of the stack storage threshold, and descending order, signed key extremes and move-only elements. Unit tests of the moved call sites and the full diff test suite pass.

[github-actions]

🎨 Perfetto UI Builds & Tests

• 2593636 (2026-09-30 22:26 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36785353550-1-ui/ui/index.html
• 6f201ba (2026-09-30 22:55 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36788076549-1-ui/ui/index.html
• e2ffcb3 (2026-10-09 19:55 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-37983021793-1-ui/ui/index.html
• b66f1a8 (2026-10-09 21:05 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-37990442548-1-ui/ui/index.html

[Vibhu-Agarwal]

The index-sort + captureless-thunk trick is neat. I went through all the call sites asking "how often, and with how many elements"; all look cold except the two interval-intersect ones (question inline).

Two things on the description:

• It lists the symbolizer among the moved sites, but there's no symbolizer change in the diff.
• Since the motivation is size, the Wasm delta might be a good number to quote, as that's where TP's code size is felt most.

[LalitMaganti]

Thanks! Rather than reverting the interval intersect sites, I made ColdSort allocation-free for small inputs, so a 3-element sort is now 13ns vs 6ns for std::sort. Addressed the rest too.

[LalitMaganti]

FYI I reworked thi a bit since your last look: instead of calling the comparator through a function pointer, callers now pass an integer key and there's a single shared std::sort on {key, index} pairs. It ends up both smaller (110KB on Linux, 147KB on Wasm) and a lot faster than the previous version.

I tested every callsite against its original sort: most are the same or faster, and the worst case is ~1.7ms extra per 100k Android log lines, which I think is fine.

[Vibhu-Agarwal]

The by-key version is both simpler to read and better on every number in the description; nice