Y'all might be interested in bench-allocators, which benchmarks mimalloc, smalloc, snmalloc, jemalloc, rpmalloc, and whatever the default Rust allocator is. smalloc is written in native Rust. mimalloc, snmalloc, jemalloc, and rpmalloc are used through Rust wrappers, which wrappers are linked to in the output file (e.g. https://github.com/zooko/bench-allocators/blob/main/benchmark-results/AppleM4Max.darwin25/COMBINED-REPORT.md). There are currently only four benchmarks in here:
- The benchmarks of the Rust simd-json project, as forked by me.
- The regex compilation benchmarks of the Rust rebar benchmarking tool, as forked by me.
- Micro-benchmarks measuring the latency of basic
malloc, free, and realloc operations, from the smalloc repo.
- A lines-of-code count: results
So the point of this issue ticket is that y'all might want to adopt some of these benchmarks into mimalloc-bench. They are inspired by and similar to mimalloc-bench's bash script design. Here's the bash script in bench-allocators that invokes subprocesses to benchmark specific codebases. Here's the benchmarking script for simd-json and here's the benchmarking script for rebar.
Here are some interesting things I learned from these benchmarks:
- The allocator can make a substantial difference in (the benchmarks of) real application code, for example the difference between best and worst in simd-json's benchmarks is 20%:
-
smalloc is competitive in performance with the best modern allocators (snmalloc, mimalloc, and rpmalloc) despite being radically simpler.
-
jemalloc and "default" (whatever the Rust runtime uses on that platform) are not as efficient as smalloc, snmalloc, mimalloc, or rpmalloc. ("Default" might be doing security-hardening work—I haven't investigated. It would probably make sense for the Rust system to disable security-hardening features since the Rust compile-time checks probably prevent almost all of the bugs that threaten users of code written in memory-unsafe languages. Buuuuut, there is unsafe { } code in Rust…) In particular jemalloc suffers a superlinear slowdown on repeated concurrent allocation, under heavy multithreading contention:
Thanks for reading. lmk what you think and if I can help!
Y'all might be interested in bench-allocators, which benchmarks
mimalloc,smalloc,snmalloc,jemalloc,rpmalloc, and whatever the default Rust allocator is.smallocis written in native Rust.mimalloc,snmalloc,jemalloc, andrpmallocare used through Rust wrappers, which wrappers are linked to in the output file (e.g. https://github.com/zooko/bench-allocators/blob/main/benchmark-results/AppleM4Max.darwin25/COMBINED-REPORT.md). There are currently only four benchmarks in here:malloc,free, andreallocoperations, from the smalloc repo.So the point of this issue ticket is that y'all might want to adopt some of these benchmarks into mimalloc-bench. They are inspired by and similar to mimalloc-bench's bash script design. Here's the bash script in bench-allocators that invokes subprocesses to benchmark specific codebases. Here's the benchmarking script for simd-json and here's the benchmarking script for rebar.
Here are some interesting things I learned from these benchmarks:
smalloc is competitive in performance with the best modern allocators (snmalloc, mimalloc, and rpmalloc) despite being radically simpler.
jemalloc and "default" (whatever the Rust runtime uses on that platform) are not as efficient as smalloc, snmalloc, mimalloc, or rpmalloc. ("Default" might be doing security-hardening work—I haven't investigated. It would probably make sense for the Rust system to disable security-hardening features since the Rust compile-time checks probably prevent almost all of the bugs that threaten users of code written in memory-unsafe languages. Buuuuut, there is
unsafe { }code in Rust…) In particular jemalloc suffers a superlinear slowdown on repeated concurrent allocation, under heavy multithreading contention:Thanks for reading. lmk what you think and if I can help!