Allocation Benchmarks
Compare allocation implementations by repeatedly allocating and deallocating memory.
Things to know about Wasm memory allocation
- Memory is never reclaimed: Once allocated, memory grows (by factors of 64 KiB) but never shrinks. Deallocated memory can be reused by the allocator within the Wasm module, so the overall memory footprint remains at its peak usage.
- 4 GB memory limit: Wasm uses 32-bit addressing, limiting addressable memory to 4 GB. While wasm64 increases this to 16 GB, it remains a Tier 3 platform in Rust that lacks wasm-bindgen support. Early testing suggests performance degradations may accompany wasm64. Small string optimizations may be less effective in Wasm than in an 64 bit environment.
- Browser differences: Allocator performance varies significantly across browsers. Make sure you test the browsers you are targeting!
- Allocator customization: Each Wasm module has its own memory allocator. By default, Rust uses a port of dlmalloc, but this can be customized to use others (like talc). All allocators have an extra layer of indirection when they need more memory as interact with the underlying browser allocator via
Memory.grow
Every run and allocator starts with a fresh heap, so there should be no performance differences between runs. This benchmark seeks to measure how much faster a bump allocator can be with its ability to pre-allocate the total amount of anticipated memory as well as coalescing everything into a single drop call.