test(runner-shared): benchmark finding module events in a memtrack artifact

[not-matthias]

TLDR: Since 5.4.0, the memory executor decodes the whole memtrack artifact after a run just to keep its few Mapping, Fork and Exec events. On artifacts with tens of millions of events, this adds minutes between memtrack's last log line and the upload. This PR only adds a benchmark for that search; the optimization is stacked on top in #578.

• Move the filter from read_mappings_from_artifact into MemtrackArtifact::decode_module_events, so the bench measures the code the runner runs. No behavior change.
• Add the memtrack_reader bench. Its artifact is laid out like memtrack writes one: allocations, forks and execs spread through the stream, and 64 mappings at the end. It runs without stacks and with an 8 KiB stack record every 400 events, and asserts that all module events are found.
• It runs at 1M events. Larger sizes take minutes per case with the current decoder under simulation; perf(runner-shared): decode memtrack frames for module events in parallel #578 adds them back.
• The artifact is generated lazily, written to a file under the target directory and mapped, so larger sizes never have to fit in memory.

Baseline, local walltime on a 32-thread machine: 258 ms without stacks, 267 ms with stacks.

[codspeed]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 31 untouched benchmarks
🆕 6 new benchmarks
⏩ 6 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
🆕	Memory	find_module_events_with_stacks[1000000]	N/A	1.1 MB	N/A
🆕	Memory	find_module_events[1000000]	N/A	1.1 MB	N/A
🆕	Simulation	find_module_events_with_stacks[1000000]	N/A	2.5 s	N/A
🆕	Simulation	find_module_events[1000000]	N/A	2.5 s	N/A
🆕	WallTime	find_module_events_with_stacks[1000000]	N/A	1.3 s	N/A
🆕	WallTime	find_module_events[1000000]	N/A	1.3 s	N/A

---

_{Comparing cod-3819-memtrack-investigate-8-minutes-spent-in-teardown (2f1f983) with main (90cc8e9)}

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[not-matthias]

@codspeedbot suggest optimizations for find_module_events_with_stacks. sort by largest estimated speedup. estimate the diff size/complexity. no need to run anything. just explore the flamegraphs

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Adds memtrack_reader benchmarks for finding module events in artifacts with and without captured stacks.

• Both cases generate 1,048,576 events, write them to a temporary file, and check the number of module events.
• Moves the existing filter into MemtrackArtifact::decode_module_events so the benchmark measures the runner’s code.
• No actionable issues found. Tests and benchmarks were not executed.

_{Reviews (1) · Last reviewed commit: 4bd93bd · Reviewed by Greptile}

[not-matthias]

Note: SIZES currently only has 1 value, since larger values would completely timeout the CI. I'm adding larger values in the stacked PR.