hahahacorn

Meta’s renewed commitment to jemalloc

https://github.com/jemalloc/jemalloc

https://engineering.fb.com/2026/03/02/data-infrastructure/investing-in-infrastructure-metas-renewed-commitment-to-jemalloc/

GitHub - jemalloc/jemalloc

Contribute to jemalloc/jemalloc development by creating an account on GitHub.

GitHub
Mar 16 at 6:12pmWeb
Show threadcarlos256Mar 16
If you need to optimize the allocator you are doing it wrong.
Show threadcbarrickMar 16

Exactly. No need to engineer an allocator. You only live once!

void* malloc(size_t size) {
void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
return (ptr == MAP_FAILED) ? NULL : ptr;
}

void free(void *ptr) { /* YOLO */ }


/s

Show threadotMar 17

That's a false dichotomy: you optimize both the application and the allocator.

A 0.5% improvement may not be a lot to you, but at hyperscaler scale it's well worth staffing a team to work on it, with the added benefit of having people on hand that can investigate subtle bugs and pathological perf behaviors.

Show threadsumtechguyMar 17

exactly. I can think of at least 5 different projects I have been on where a better allocator would made a world of difference. I can also think of another 5 where it probably would have been a waste of time to even fiddle with.

but as usual there is an xkcd for that. https://xkcd.com/1205/

One project I spent a bunch of time optimizing the write path of I/O. It was just using standard fwrite. But by staging items correctly it was an easy 10x speed win. Those optimizations sometimes stack up and count big. But it also had a few edges on it, so use with care.

Is It Worth the Time?

xkcd
Show threadsaagarjhaMar 17
Glad we have super slow allocators then