Benchmarks

compatmalloc prioritizes security over raw performance. This page describes the performance characteristics, overhead sources, and how to run benchmarks to measure the impact on your workloads.

Latest CI Results (x86_64)

Auto-generated by CI on 2026-03-08 04:47 UTC from commit 760fbb2. Results are from GitHub Actions runners (shared infrastructure) and may vary between runs. Each allocator is run 3 times; the best (lowest latency) result is kept.

Multi-Allocator Comparison

Ratio interpretation: Latency ratio < 1.0 = faster than glibc. Throughput ratio > 1.0 = faster than glibc.

Hardened allocators: compatmalloc, scudo. These have security features (guard pages, quarantine, etc.) that add overhead vs. pure-performance allocators.

Peak RSS measured via /usr/bin/time -v during a single benchmark run. Hardening features (quarantine, guard pages) increase memory usage.

malloc/free Latency by Size (glibc)

  size=      16:     12.8 ns
  size=      32:     12.3 ns
  size=      64:     12.3 ns
  size=     128:     12.4 ns
  size=     256:     12.3 ns
  size=     512:     12.3 ns
  size=    1024:     12.3 ns
  size=    4096:     23.2 ns
  size=   16384:     23.5 ns
  size=   65536:     24.0 ns
  size=  262144:     24.4 ns
  size=      16:     15.9 ns
  size=      64:     16.6 ns
  size=     256:     26.8 ns
  size=    1024:     28.5 ns
  size=    4096:     70.3 ns
  size=   65536:    764.3 ns

malloc/free Latency by Size (compatmalloc)

  size=      16:     14.9 ns
  size=      32:     14.5 ns
  size=      64:     14.5 ns
  size=     128:     14.7 ns
  size=     256:     14.5 ns
  size=     512:     14.5 ns
  size=    1024:     14.5 ns
  size=    4096:     14.5 ns
  size=   16384:     14.5 ns
  size=   65536:     24.2 ns
  size=  262144:     24.2 ns
  size=      16:     13.7 ns
  size=      64:     13.8 ns
  size=     256:     14.2 ns
  size=    1024:     19.8 ns
  size=    4096:     60.7 ns
  size=   65536:    765.3 ns

Multi-threaded Throughput (glibc)

  threads=1:  74.53 Mops/sec
  threads=2: 144.38 Mops/sec
  threads=4: 171.84 Mops/sec
  threads=8: 167.43 Mops/sec

Multi-threaded Throughput (compatmalloc)

  threads=1:  65.48 Mops/sec
  threads=2: 125.34 Mops/sec
  threads=4: 150.78 Mops/sec
  threads=8: 145.36 Mops/sec

Real-World Application Overhead

Application benchmarks measure wall-clock time for real programs (Python, Redis, nginx, SQLite, Git). Overhead = (compatmalloc_time / glibc_time - 1) * 100%.

Performance characteristics

Expected overhead

Compared to glibc's ptmalloc2, compatmalloc adds overhead from several sources:

For small allocations (16-256 bytes), the dominant costs are the metadata table operations and the canary/poison fills. For large allocations, the mmap/munmap syscalls dominate regardless of hardening.

Size class efficiency

The slab allocator uses 4-per-doubling size classes, which means internal fragmentation is at most 25% for any allocation. Size classes range from 16 bytes to 16,384 bytes (36 classes total).

Arena contention

With the default arena count (one per CPU), contention is low for most workloads. Programs with many threads performing high-frequency allocations may benefit from explicitly setting COMPATMALLOC_ARENA_COUNT to a higher value.

Running benchmarks

Microbenchmark suite

The benchmark suite is a standalone binary that measures allocator performance via LD_PRELOAD:

# Build the library and benchmark
cargo build --release
rustc -O benches/src/micro.rs -o target/release/micro

# Run with glibc (baseline)
ALLOCATOR_NAME=glibc ./target/release/micro

# Run with compatmalloc
ALLOCATOR_NAME=compatmalloc \
  LD_PRELOAD=./target/release/libcompatmalloc.so \
  ./target/release/micro

Full comparison script

To compare against multiple allocators (glibc, jemalloc, mimalloc, scudo):

./benches/scripts/run_comparison.sh

Disabling hardening for comparison

To measure the overhead of hardening features, build with no features:

cargo build --release --no-default-features
ALLOCATOR_NAME=minimal \
  LD_PRELOAD=./target/release/libcompatmalloc.so \
  ./target/release/micro

LD_PRELOAD benchmarks with external programs

For realistic benchmarks, test with real applications:

# Time a build with and without compatmalloc
time cargo build --release

time LD_PRELOAD=./target/release/libcompatmalloc.so \
  cargo build --release

# Python workload
time python3 -c "
import json
data = [{'key': str(i), 'value': list(range(100))} for i in range(10000)]
result = json.dumps(data)
parsed = json.loads(result)
"

time LD_PRELOAD=./target/release/libcompatmalloc.so python3 -c "
import json
data = [{'key': str(i), 'value': list(range(100))} for i in range(10000)]
result = json.dumps(data)
parsed = json.loads(result)
"

Tuning for performance

If the overhead is too high for your use case, you can selectively disable features:

Weighted composite overhead

The headline "Weighted Overhead" metric computes a single overhead percentage that accounts for real-world allocation size distributions. Instead of reporting only the 64-byte latency, we weight each allocation size by its frequency in typical programs (based on jemalloc/tcmalloc telemetry data):

Formula: overhead = (Σ weight_i × (alloc_latency_i / glibc_latency_i) − 1) × 100%

A weighted overhead of +15% means compatmalloc is 15% slower than glibc across a representative workload mix. Negative values indicate compatmalloc is faster.

Methodology notes

When benchmarking allocators, keep the following in mind:

1. Warm up the allocator. The first few allocations may be slower due to slab initialization and metadata table growth.
2. Test with realistic workloads. Microbenchmarks of malloc/free loops do not represent real application behavior.
3. Measure RSS, not just time. Hardening features (quarantine, guard pages) increase resident memory. Use getrusage or /proc/self/status to measure VmRSS.
4. Account for variance. Run benchmarks multiple times and report medians. Allocator performance can be sensitive to ASLR and system load.
5. Best-of-3 selection. CI results use the minimum latency and maximum throughput from 3 runs. This filters out noise from shared infrastructure while reflecting the allocator's true capability.
6. Compare against other allocators. The comparison table includes jemalloc and mimalloc (performance-focused) alongside scudo (hardened, like compatmalloc). This provides context for the overhead of hardening features.