Comment by thewisenerd
2 days ago
indeed! most image processing golang services suggest/use jemalloc
the top 3 from https://github.com/topics/resize-images (as of 2025-06-13)
imaginary: https://github.com/h2non/imaginary/blob/1d4e251cfcd58ea66f83...
imgproxy: https://web.archive.org/web/20210412004544/https://docs.imgp... (linked from a discussion in the imaginary repo)
imagor: https://github.com/cshum/imagor/blob/f6673fa6656ee8ef17728f2...
Those three all use libvips as the image processing engine, fwiw, so it's maybe not a very wide survey.
libvips is fairly highly threaded and does a lot of alloc/free, so it's challenging for most heap implementations.
Yep, imgproxy seems to use libvips, that recommends jemalloc. I was checking and this is a funny (not) bug report:
https://github.com/libvips/libvips/discussions/3019
Hello, libvips author here. This is probably the canonical thread about libvips and memory fragmentation, and the funniest graph:
https://github.com/lovell/sharp/issues/955#issuecomment-5458...
(that specific graph is for switching from glib to the musl memory allocator, but jemalloc gives a very similar result)