如果您关心性能，请不要使用 musl

我职业生涯的大部分时间都在 JVM 中工作，其中还涉及 Python。因此，当我第一次遇到与容器化 Bifrost 不兼容的 libc 时，GPT 建议使用 musl 作为解决方案，我不仅跳上了它，而且还将我的其他 Rust 项目移到了 musl。具有单一实现支持的自包含二进制文件？是的，请！然后我的同事 Ryan 提到 musl 已知有一个次优分配器，并向我指出 Daniel Raneland 的文章。呃哦。我决定测量一下，看看它有多糟糕。所以，是的：musl 的分配器确实很糟糕。甚至很可怕。并且（与我读过的一些文章相反）不仅在高并发场景下；这些数字来自 4 核 EC2 VM，Bifrost 会相应调整其线程池的大小。对于用户来说，这是一把非常糟糕的步枪，老实说，我认为 musl 应该在没有分配器的情况下发布，并让你选择一个。然后，如果您出于某种原因选择了非常糟糕的一个（也许代码占用空间真的很小？idk），那么这就是您的责任，而不是“哦，对不起，您没有阅读细则吗？哈哈，这不是一个有趣的惊喜吗！”但不幸的是，“只使用 mimalloc”[或 jemalloc] 并不是一根能获得与 glibc 同等性能的魔杖；带有 mimalloc 的 musl 仍然慢 26%。因此，我深入研究了表现出最差回归的两种任务类型。 scan_usages 确实从 mimalloc 中获得了一些好处，但仍然比 glibc 慢。另一方面，structural_clone_smells 几乎不分配；有和没有mimalloc 的musl 的区别是噪音。然而 s_c_s 比 scan_usages 更容易受到 musl 的影响。事实证明，分配器并不是 musl 中唯一次优的代码，而且几个常见的内存例程特别慢： 简单性仍然不是免费的，我将保留较小的项目，其中 25% 的慢速并不重要（例如 Hel），musl-only 是为了简单性，并添加了 mimalloc。但本着不留下更多已装弹枪的精神，我们从对性能更加敏感的 Bifrost 中删除了 musl 作为预建选项。