Benchmark Report: Analyzing the Time-Space Trade-off in Memory Allocators (hakozuna vs tcmalloc)

#tcmalloc #programming #cpp

Introduction

I have been developing a custom memory allocator called hz3.
I recently ran a set of single-threaded benchmarks (alloc-test, espresso) to compare its performance against industry standards: tcmalloc (Google) and mimalloc (Microsoft).

The results highlight a significant trade-off between execution speed and memory footprint (RSS).

Benchmark Results

The following tests were run on a Ryzen 9 9950X environment (RUNS=5, Median).

Observations

1. The Cost of Speed
tcmalloc achieved the fastest execution time in both tests. However, it consumed nearly 3.7x more memory than hakozuna in the espresso benchmark (9.7MB vs 2.6MB).
This suggests that tcmalloc aggressively caches freed memory in thread-local storage to minimize locking and CPU overhead, trading memory usage for throughput.

2. The Cost of Frugality
hakozuna consistently maintained the lowest RSS. This is due to its aggressive purging strategy (returning unused pages to the OS) and compact metadata design.
The trade-off is higher CPU overhead (13-26% slower) caused by the additional logic required to manage memory density and page releasing.

Conclusion

There is no "perfect" allocator.

For latency-sensitive applications where RAM is abundant, tcmalloc or mimalloc remains the superior choice.
For memory-constrained environments (e.g., high-density microservices, embedded systems), hakozuna offers a viable alternative by significantly reducing the memory footprint at the cost of some CPU cycles.

This benchmark serves as a reminder that "performance" is not a single metric; it is always a balance between time and space.