確かに、これはデバッグシンボル込みの話だよね。数年前のChromeのデバッグビルドは5GBくらいだったし、今はもっと増えてるだろうね。オブジェクトファイルのサイズが大きすぎて、リンク中にラップトップがRAM不足になったこともあったな。デバッグシンボルってなんでこんなに大きいんだろう？C++の場合、プログラム内のあらゆる型のインスタンスに対して詳細な型情報が含まれてるから、フィールドの型（再帰的に）、メソッドのシグネチャ、ローカル変数の型と位置など、すごい量のデータが生成されるんだよね。これって「普通」なプロジェクトでもかなりのデータ量になる。さらに悪いことに、C++では動的リンクのメリットがあまりないんだ。ヘッダーファイルで定義されたテンプレートは簡単に共有ライブラリに入れられないし、ABIの違いで動的ライブラリは同期して更新しなきゃいけないし、モジュール間の重複も避けられない（インライン関数やテンプレートのおかげで）。古いバージョンの.soが「詰まる」と、デプロイが完全に壊れちゃうこともあるから、単一のバイナリをデプロイするよりもずっと厄介だよね（新しいバージョンか古いバージョンしか手に入らない、壊れたサービスはダメ）。

確かに、彼らはGoogleで働いてたから、エンジニアリングの判断が普通じゃないんだよね。25 GiBのバイナリがスタート時の0.25%のスピードアップに価値があると判断するかもしれないし、それが数千万ドルの差につながることもある。誰もGoogleのやり方を真似するべきじゃないけど、考えるのは面白いよね。

ダイナミックリンクだからって全体のサイズが小さくなるわけじゃないよ。逆に言うと、DLLはデッドコード削除の障壁になるからね。25GBはヤバすぎるし、開発の初期段階で何かがひどく間違ったに違いないよ（デバッグ情報を含めて出荷するのも、そもそも意味がわからないし）。

どうせ全部が一種のコンテナ（Dockerじゃないけど）に入ってるから、全然変わらないよ。もし、アプリが動く可能性のあるすべてのボーグマシンにそのライブラリをベースイメージとして配布することを提案してるなら、それは明らかに無理だね。

これ、Googleで働いてた時もずっと気になってたことなんだ。すごい計算とストレージのインフラがあって、年々クレイジーになっていったけど（パフォーマンス、スケーラビリティ、冗長性の面で）、バイナリのサイズが大きすぎて、運用が遅く感じてた。コマンドラインのバイナリを実行するのも遅いし、デプロイ用のバイナリをビルドするのも遅い。バイナリをデプロイするのも遅い。バイナリのサイズが増えるたびに「インフラをスケールアップしよう！」って答えが返ってくるだけで、「こんなクレイジーなことはやめよう」って考えにはならなかった。私が辞める頃には、後者に向けた新しい取り組みが始まって、「もっと早く制限を設けるべきだったかも」って感じがあったけど、既存の膨張に制限を後付けするのはすごく難しいことだった。

もし25GBの実行ファイルがあるなら、それが一つのバイナリ実行ファイルか100個かは関係ないと思う。何かがひどくひどく間違ってる。4GBのバイナリを見たことはないけど、PDBファイルが4GBに達して問題が起きたことはある。デバッグシンボルがそんなに大きくなるのは全然あり得ることだね。それについてはまあ、いいかな。

https://systemd.io/PORTABLE_SERVICES/ Systemdとポータブル？

俺にとって驚きなのは、-gsplit-dwarfを使わないでデバッグ情報と「普通サイズ」のバイナリを分けないことだね。

CALLをJMPと呼ぶような緩い言語だと思うけど、大きなコードモデルを嫌う理由の2つのうち、レジスタプレッシャーはその特定のスニペットには関係ないよ。コールを実行してるから、ABIはコール間で保持されないレジスタを定義してるし、そのうちの1つに宛先を書き込んでもレジスタプレッシャーには影響しないよ。