[adityapatadia]

Jason, here is a story about how much your work impacts us. We run a decently sized company that processes hundreds of millions of images/videos per day. When we first started about 5 years ago, we spent countless hours debugging issues related to memory fragmentation.

One fine day, we discovered Jemalloc and put it in our service, which was causing a lot of memory fragmentation. We did not think that those 2 lines of changes in Dockerfile were going to fix all of our woes, but we were pleasantly surprised. Every single issue went away.

Today, our multi-million dollar revenue company is using your memory allocator on every single service and on every single Dockerfile.

Thank you! From the bottom of our hearts!

[thewisenerd]

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...

[tecleandor]

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

[jcupitt]

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.

[laszlojamf]

I really don't mean to be snarky, but honest question: Did you donate? Nothing says thank you like some $$$...

[onli]

It was a meta project and development ceased. For a regular project that expectation is fine, but here it does not apply IMHO.

[adityapatadia]

We regularly donate to project via open collective. We frankly did not see here due to FB involvement I think.