作者：Jonathan Ellis — 2026年8月27日 我职业生涯的大部分时间都在JVM内部工作，偶尔使用Python。因此，当我第一次在容器化的Bifrost中遇到不兼容的libc，并且GPT建议使用musl作为解决方案时，我不仅马上尝试了，还将其他Rust项目也迁移到了musl。自包含的二进制文件有单一的实现支持？是的，太好了！然后我的同事Ryan提到，musl有一个已知的劣质分配器，并给我指向Daniel Raneland的文章。哦，不。于是我决定进行测量，看看情况有多糟。所以，是的：musl的分配器确实很糟糕，甚至可以说很糟糕。并且（与我读过的一些文章相反）并非仅在高并发场景下；这些数字来自4核EC2虚拟机，而Bifrost会相应地调整其线程池。这对用户来说是一个非常糟糕的隐患，老实说，我认为musl应该不包含分配器，应该让你自己选择一个。然后，如果你因为某种原因（也许代码占用空间真的很小？我不知道）选择了一个非常糟糕的分配器，那是你自己的责任，而不是“哦，不好意思，你没看到小字吗？哈哈，那不是个惊喜！”但不幸的是“只需使用mimalloc”[或jemalloc]并不能神奇地让musl的性能与glibc平起平坐；使用mimalloc的musl仍然慢26%。因此，我深入挖掘了显示出最糟糕回归的两种任务类型。scan_usages确实从mimalloc中获益，但仍然比glibc慢。另一方面，structural_clone_smells几乎不进行分配；在musl中使用和不使用mimalloc的差异几乎可以忽略不计。然而，s_c_s在musl中的损失比scan_usages要更大。事实证明，分配器并不是musl中唯一的劣质代码，几种常见的内存例程特别缓慢：简单性仍然不是免费的。我打算将25%慢无关紧要的小项目（如Hel）仅使用musl以保持简单，添加mimalloc。但为了不留下更多的隐患，我们将从对性能更敏感的Bifrost中移除musl作为预构建选项。