Skip to main content
Allocators are a common source of benchmark variance. Their cost depends on the operating system, the allocator implementation, and its version. If you are optimizing your own code and the allocator itself is not what you are measuring, that cost is noise in your measurements.

​
How it works

CodSpeed tags every flamegraph frame that belongs to an allocator, covering the standard allocation functions, common allocators such as jemalloc and language-runtime allocators. With allocation exclusion enabled, CodSpeed sums the time spent in those frames, including everything they call, and subtracts it from the reported benchmark value. The flamegraph still shows the allocator frames, marked with an Allocator tag in the tooltip. Only the reported benchmark value changes.

​
When to use it

  • Exclude allocations when allocator noise dominates a micro-benchmark and you are optimizing your own code.
  • Keep allocations included when the allocator itself is what you are measuring or optimizing.
Allocation exclusion also removes the time spent in allocations made by your own code, so a new allocation in a hot path may not show up as a regression. Run the memory instrument on the same benchmarks to see changes in allocation count and memory usage:
Allocation exclusion complements the allocator-variance strategies in Reducing allocator variance. Tuning or swapping the allocator reduces variance, while exclusion leaves the allocator cost out of the reported value entirely.

​
Enable it

Pass the flag to the CodSpeed CLI:
In GitHub Actions, enable allocation exclusion with the dedicated action input:
.github/workflows/codspeed.yml

​
Next Steps

Reducing Variance

Techniques to make your benchmarks more stable across runs.

Unexpected Regressions

Understand why benchmarks can regress without code changes.