性能敏感项目慎用 musl
Don't use musl if you care about performance
作为一名长期在 JVM 和 Python 生态工作的开发者，我最初为了容器化部署的便利，将 Rust 项目迁移到了 musl。然而，同事 Ryan 的提醒让我意识到 musl 的内存分配器可能存在性能隐患。经过实测，musl 的分配器表现确实糟糕，即便替换为 mimalloc，整体性能仍比 glibc 慢 26%。深入分析发现，问题不仅在于分配器，musl 中多个基础内存原语的效率也远低于预期。因此，对于像 Bifrost 这样对性能极其敏感的项目，我们决定移除 musl 预编译选项，仅在小项目中为了简化而保留它。
这是一个留给用户的危险陷阱，老实说，我认为 musl 应该默认不带分配器，让用户自行选择。
HN 评论区
59- matherial
如果你的算法进行了大量的小内存分配，导致分配器成为瓶颈，那你从一开始就做错了。分配器必然伴随着大量开销，因为它需要适应各种使用场景、避免内存碎片，并且理想情况下还要实现各种安全检查。如果你在做分配密集型的工作，那你很可能是在频繁分配和释放大量相同的结构体，这种情况下，更好的做法是申请一块连续内存，然后以特定任务的方式自行管理。
但现实是，几乎没人真正关心性能，因为至少在短期内，计算资源比专业知识和人力更便宜。一切都在变得臃肿和缓慢，我们只是通过增加 CPU 核心数、内存容量和频率来弥补。
- marssaxman
人们的观点差异太大了。对我来说，慢 26% 听起来算不上“糟糕”；这更像是为了 musl 带来的便利而付出的合理代价。如果 musl 的分配器慢 2.6 倍，我可能会说“不太行”……但要称得上“糟糕”，我觉得差距得达到一个数量级才行！
- lrvick
我真的很难理解那些抱怨 musl 中那个最小可用占位符 malloc 的声音。难道真有人试图在性能关键场景中使用 malloc-ng 吗？
我们整个 Linux 发行版都是基于 musl 构建的，但对于高性能需求，我们会把默认 malloc 替换成 mimalloc，这何乐而不为呢？两全其美。
https://codeberg.org/stagex/stagex/src/branch/main/packages/...
- bloppe
这只是“性能”的一个方面。glibc 的分配器可能更快，但它也消耗更多内存。
想进行更深入的技术讨论，请看：https://github.com/sharkdp/fd/issues/710
- mattrighetti
前几天刚发过这个，不过整个 musl 分配器的问题似乎已经广为人知了 [0]