wee_alloc

wee_alloc is a Wasm-enabled, elfin memory allocator designed to be as small as possible in compiled code size. Built by the rustwasm working group, it trades raw allocation speed for a minimal footprint, adding roughly a kilobyte of .wasm to your binary instead of the tens of kilobytes a general-purpose allocator would.

It is intended for size-sensitive targets like WebAssembly modules shipped to browsers, where every byte over the wire matters. You wire it in as Rust’s #[global_allocator], and it handles the small, infrequent allocations typical of Wasm workloads.

What You Get

• A drop-in #[global_allocator] implementation for Rust programs
• A very small compiled footprint, roughly a kilobyte of added .wasm
• no_std support suitable for constrained and embedded-style targets
• Sensible behavior for the small, infrequent allocation patterns common in Wasm

Common Use Cases

• Shrinking the size of Rust-compiled WebAssembly modules shipped to browsers
• Serving as the global allocator in size-constrained no_std projects
• Replacing the default allocator when binary size outweighs allocation speed

Under The Hood

Architecture - wee_alloc implements Rust’s GlobalAlloc trait over a first-fit free list of small allocation cells. Its design deliberately favors minimal code size: it keeps a compact free-list structure and delegates to the host’s page-growth primitive (memory.grow on Wasm) when it needs more memory, rather than carrying the elaborate size-class machinery of a general allocator.

Tech Stack - Pure Rust (with a small amount of Shell for build glue), no_std, targeting wasm32 primarily but with backends for other platforms. It plugs into the toolchain via the #[global_allocator] attribute and requires no runtime dependencies.

Code Quality - The crate is mature and stable (last released 0.4.5), with a test suite and CI history, though it is effectively in maintenance mode with little recent activity. The codebase is small and focused, and the README is explicit that it optimizes for size over speed and is not a general-purpose allocator.

API Design - Usage is a two-line setup: declare a static WeeAlloc and annotate it with #[global_allocator]. There is essentially no API surface to learn beyond that, so the learning curve is trivial; the main consideration is understanding the size-versus-speed tradeoff before adopting it.