Run with just wasm-perf. Source code can be found in wasm-perf/.
Run withjust wasm-size. Source code can be found in wasm-size/.
-
If all you care about is WebAssembly module size, use
lol_alloc -
If all you care about is performance, use
Talc -
If you want a "best of both worlds" then use
Talc(consider setting"disable-realloc-in-place"or"disable-grow-in-place"), or RLSF'sSmallGlobalTlsf. -
DLmallocand RLSF'sGlobalTlsfare worse in both size and performance toTalc.
Talc's default WebAssembly configuration is less memory-efficient compared to the alternatives. The defaults are chosen as WebAssembly modules rarely push the limits of system memory, whereas network bandwidth and runtime performance dictate the latency end-users experience, and therefore is often crucial.
Expect a 10%-15% higher runtime memory usage, though I've only taken rough measurements. Your mileage may vary. To test for yourself, you can use core::arch::wasm32::memory_size::<0>() to see how much memory the WebAssembly module is using.
Talc's memory efficiency is almost entirely dependent on the Binning configuration used. You can swap out WasmBinning if desirable.
Using WasmGrowAndExtend instead of WasmGrowAndClaim will also help.
By default, Talc claims new WebAssembly pages on demand using the WasmGrowAndClaim OOM handler.
An alternative to consider is WasmGrowAndExtend:
- Extends the heap instead of claiming new heaps. This reduces memory fragmentation and thus may improve memory efficiency somewhat.
- Requires ~250 more bytes of WebAssembly module size due to pulling in the
Talc::extendcode.
use talc::{wasm::*, cell::TalcSyncCell};
#[cfg(all(not(target_feature = "atomics"), target_family = "wasm"))]
#[global_allocator]
static TALC: TalcSyncCell<WasmGrowAndExtend, WasmBinning> = TalcSyncCell::new_wasm(WasmGrowAndExtend::new());
