パフォーマンスを気にするならmuslを使わないで

私はキャリアのほとんどをJVM内で、Pythonを副業として過ごしてきました。そのため、コンテナ化されたBifrostで互換性のないlibcに初めて遭遇し、GPTがmuslを解決策として提案したとき、私はそれに飛びついただけでなく、他のRustプロジェクトもmuslに移行しました。単一の実装に裏打ちされた自己完結型のバイナリ？はい、お願いします！その後、同僚のRyanがmuslは最適ではないアロケーターで知られていると述べ、Daniel Ranelandの記事を教えてくれました。まずい。私はそれがどれほど悪いか測定することにしました。それで、はい：muslのアロケーターは確かに悪いです。ひどいものです。そして（私が読んだ記事のいくつかと異なり）高同時実行シナリオだけでなく、これらの数値は4コアEC2 VMからのもので、Bifrostはスレッドプールをそれに応じてサイズ設定しています。これはユーザーに任せるには本当に悪いフットガンであり、正直なところ、muslはアロケーターなしで出荷し、ユーザーに選択させるべきだと思います。もしあなたが何らかの理由で（コードフットプリントが非常に小さいからかもしれません？知りません）本当に悪いものを選択した場合、それはあなたのせいです。「ああ、ごめんなさい、細則を読みませんでしたか？笑、楽しいサプライズでしたね！」というのではなく。しかし残念ながら、「mimallocを使うだけ」[またはjemalloc]はmuslのパフォーマンスをglibcと同等にする魔法の杖ではありません。mimallocを使ったmuslは依然として26%遅いです。そこで、最も悪い回帰を示した2つのタスクタイプをさらに掘り下げました。scan_usagesはmimallocからいくらか恩恵を受けますが、glibc上よりも遅いです。一方、structural_smellsはほとんど割り当てません。muslでmimallocを使用する場合としない場合の差はノイズです。それにもかかわらず、s_c_sはscan_usagesよりも比例して、muslからさらに悪化します。アロケーターだけがmuslの最適化されていないコードではなく、いくつかの一般的なメモリルーチンが特に遅いことがわかりました。シンプルさはまだ無料ではありません。25%遅くても問題ない（Helのような）小規模プロジェクトでは、mimallocを追加してmuslのみを使用し続けます。しかし、これ以上ロードされたフットガンを残さないという精神で、パフォーマンスがより重要なBifrostのプリビルドオプションからmuslを削除します。