Repository navigation
perf: use mimalloc as the runner's global allocator - #581
Conversation
Merging this PR will improve performance by 32.52%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | WallTime | encode_events_realistic[16] |
130.5 ms | 92.5 ms | +41.1% |
| ⚡ | WallTime | encode_events_realistic[8] |
128.6 ms | 103.3 ms | +24.46% |
Tip
Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.
Comparing cod-3819-runner-mimalloc (5ee7e58) with main (5ff86d7)
Footnotes
-
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 this is already done as part of #531 |
5449177 to
3167179
Compare
|
The release binary targets musl, whose allocator is slow on many small allocations and serializes threads. Post-processing a memory run decodes the whole memtrack artifact with one or more allocations per event, which on a 62M-event artifact took 8-19 minutes in CI with the musl build against 1-2 minutes with glibc for the same code. Use mimalloc, as memtrack already does, so the runner no longer depends on the libc allocator.
f907a35 to
5ee7e58
Compare
TLDR: The released runner is a musl build, and musl's allocator is slow on many small allocations and serializes threads. Post-processing a memory run decodes the whole memtrack artifact with allocations per event, so it took 8-19 minutes on the largest platform shard. The runner now uses mimalloc, as memtrack already does.
mimallocas the global allocator in thecodspeedbinary.Time from memtrack's last log line to the end of post-processing, platform memory shards, musl build like the release, 3 runs each (medians, seconds):
Review note: affects every allocation in the runner, not just the memtrack decode.