Using Alpine and musl instead of GNU libc affect performance?


Like many others we’re currently using Alpine images for our deployments. Specifically at the moment we rely on:

When looking around for a current unrelated issue i stumbled upon this issue Overrun stack and heap OTP-26.0 · Issue #7292 · erlang/otp · GitHub

which had this comment

This made me curious, and I didn’t want to pollute the issue with unrelated comments so I thought I would ask my question here instead.
Looking around in the forum and other places I can’t find any information stating that performance would be different depending on if your system is using GNU libc or musl and since Alpine images are very popular and by default rely on musl I felt it warranted a post.


Is there any performance difference if I use a images such as Alpine that rely on musl rather than for example a Ubuntu image with libc for production deployments? and is any such difference jit related?

Thank you in advance.


Yes, there’s a significant loss in performance with musl. I made a PR for OTP 27 that will remove these differences, the comment describes things in a bit more detail:


Thanks for the insight!

Do you have a ballpark estimate of what the performance difference would be prior to OTP 27?


Super interesting. I thought the performance difference would be due to the default allocator in musl being slower. I know Android uses different defaults to improve performance.

Also interested if there is any performance difference with OTP 27. :thinking:

Super excited for the new json module being included by default.

1 Like

~10-15% in sequential code.



I wanted to check for the json module doc… But it was broken on the RC2 news page…
but I suspected that it might be a newer news update, indeed here is the RC3 release page: Erlang/OTP 27.0 Release Candidate 3 - Erlang/OTP

But hey!!
Look at the doc for the json module: json — stdlib v6.0

Looks familiar right?!

I’m not an erlang developer but from time to time I was looking at the Erlang Docs and I can’t express enough how excited I am for this doc update! Kudos to the Erlang/Elixir folks!

1 Like