I've moved on to optimizing libghostty Wasm runtime memory usage and I am learning a lot! The first discovery: Zig's `std.heap.MemoryPool` is very bad for Wasm! We replaced it with a custom Wasm-specific pool that lowered libghostty's required terminal memory by 75% without any measurable throughput impact. Some background: `std.heap.MemoryPool` is a very high performance memory pool implementation for identically sized items directly in the Zig standard library. For non-wasm targets, its very good! We use it a lot! But there is a major problem due to the interaction of two separate behaviors: first, the Zig std memory pool grows by 1.5x whenever it has no free space. To grow, it asks the backing allocator, which is usually general-purpose. On Wasm targets, that general-purpose allocator is the BrkAllocator which grows by power-of-two for big allocation slots (what we were hitting). On native (non-wasm) targets, this just gets increasingly large virtual memory allocations, which is fine! Good, even! Virtual memory mappings are cheap and the total mapped memory isn't resident/physical until it's used. Allocation syscalls are expensive and its better to get too much. But wasm is not like that. Every linear memory growth is immediately measured, zeroed, resident memory. Second, memory growth doesn't require a "syscall" in the same sense/overhead of the word. The result is you get really big linear memory growth in WebAssembly and it looks/feels bad in web inspector and saves absolutely nothing on future IO. We replaced it with a very simple pool (~20 lines of effective code) that grows the linear memory by exactly 1 item size when it needs it and maintains a module-global free list (assumes single-threaded Wasm module) so same-item pools are shared globally. PR here: