Bun のコンパイル時間を理解するためのビルド可視化工具を作成しました

2026/09/12 23:45

Bun のコンパイル時間を理解するためのビルド可視化工具を作成しました

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

著者はbuildprofを開発した。これは、ソフトウェアのコンパイル時間をプロファイリングおよび可視化するためのオープンソース Linux トレースツールであり、バーの幅が持続時間を示し、左から右への移動が時間の流れを示す視覚的時間線(visual timelines)を生成するものである。この革新は、

strace
ninjatracing
などの既存ツールの不足を解消するものであり、これらのツールは複雑なサブプロセスツリーや特定のビルドワークフローを捕捉できないことがよくある。プロジェクトの動機は、Bun 1.4.0 の Rust ビルドがその Zig 前身よりも大幅にパフォーマンスを発揮しているという観察に基づいていた。6 コア VM でのベンチマークでは、Zig エポックの Full LTO ビルドには約 24 分かかり、外部の JavaScriptCore リンカーによって支配的であり、Rust ThinLTO ビルドは 90 以上の内部 crate 間の並列処理によりわずか約 5 分しかかからなかった。プロファイリングの結果、Bun のコード自体を Full LTO から ThinLTO に切り替えるだけでは僅かな向上(約 4 分の削減)しか得られなかったが、外部依存項(WebKit と ICU)を互換性のある ThinLTO 設定で再ビルドすることで逐次的なボトルネックを解消し、全体時間を劇的に削減できた。技術的には、buildprof はプロセス記録には
ptrace
、ファイルシステムインターセプションには
seccomp
フィルターを利用しており、カスタマイズされた Perfetto UI 内で直接依存関係のリンクを明確に可視化することが可能である。

本文

buildprof: ビルド時間の謎を可視化するオープンソース・プロファイラー

buildprof(GitHub)は、Linux 環境下でソフトウェアをコンパイルする際に時間をどこに費やしているかを示すためのオープンソースのトレーシングツールです。

buildprof
を使用することで、クリーンビルドの実況を可視化し、並列化の効率不良や重複処理、依存関係のダウンロード遅延、巨大なコンパイラ/リンカーへの呼び出しなどの問題箇所を明確に特定できます。

使用方法

非常に簡単です。既存のビルドコマンドの前に

buildprof --
を付けるだけです。

  • buildprof -- make -j16
  • buildprof -- cargo build
  • buildprof -- ninja -C out/target
  • buildprof -- just build
  • buildprof -- ./dev/custom-build-script.sh

動作原理

ビルドコマンドが起動するすべてのプロセス(およびそのサブプロセス)を記録し、一つのタイムライン上に配置します。

  • 時間: 左から右へ進みます
  • バーの幅: 実行期間を示します
  • 親子関係: 子プロセスは親プロセスの直下に配置されます

開発動機:Bun のビルド速度への疑問

開発のきっかけは、Bun JavaScript runtime の首席アーキテクトである Jarred Sumner 氏のツイートに対する疑問です。

当初の疑惑

  • 主張: 「Bun の新しい Rust ベースのビルドは、旧来の Zig ベースのビルドよりも5 倍以上高速である」
  • 直感: 通常、同様の複雑さを有する場合、Zig プロジェクトの方が Rust よりも速くコンパイルされる傾向があります。
  • 疑問: この性能差の真の要因は何なのか?

重要な背景情報 (LTO)

ツイートの詳細には以下の点が含まれていました。

  • Zig ベース: Full LTO(リンク時間最適化)を使用
  • Rust ベース: ThinLTO を使用
  • 技術的差:
    • Full LTO
      はコンパイルユニットを一つの巨大な最適化タスクに統合します。
    • ThinLTO
      は並列実行を可能にするため、より分離性が高く、効率的です。

検証と調査:24 分 vs 5 分の実績

まず数値の再現を試みました(6 コア 12 スレッドの Linux VM)。結果は Jarred 氏の発表とほぼ一致しました。

項目Zig エポック (報告/実測)Rust エポック (報告/実測)
CI メジアン30m06s / 24m24s5m37s / 5m40s

問題の所在:なぜ Zig は遅いのか?

  • 仮説: Zig コンパイラ単体の遅さか、Full LTO のリンク処理か、それとも他の要因か?
  • 解決策: プロセスツリーを可視化することで、「いつ」「何が」「どのくらい」時間を費やしたかを追跡しました。

ビルドのプロセスツリーと可視化の利点

ビルドコマンドは単なるプログラムの実行ではなく、複数のツールが連鎖的に作業を行うプロセスツリーです。

プロセスツリーの構造例 (Rust)

cargo
  └── rustc
      └── cc
          └── collect2
              └── ld.lld

buildprof の視覚化機能

  1. ビルドシステム非依存: Cargo、Ninja、Make などに対応(プロセス起動を共通認識するため)。
  2. カスタムスクリプトの追跡: 上位スクリプト(セットアップ系)と下位スクリプト(ジェネレーター系)の両方を可視化。
  3. ファイル活動の追跡: プロセス間のファイル入出力(読み書き)を記録し、矢印で連結関係をグラフ化できます。

Bun の CI ビルドにおけるボトルネックの特定

1. Zig エポック:リンカーが時間を支配している

buildprof
で Zig ベースのビルドを記録したところ、
ld.lld
リンカーへの呼び出し
が問題であることを突き止めました。

  • 時間: 単独で 16 分以上稼働し、全体時間の約 2/3 を占めていました。
  • 要因: Full LTO のリンク処理です。リンカーは単なる結合ではなく、プログラム全体に対するコンパイラのパスを実行しています。

改善策:ThinLTO に切り替え

--compiler-traces
オプションを有効にし、LLD の内部イベントを追跡した結果、時間配分が明確になりました。

  • 効果: Link-Time Optimization の設定変更により、リンク時間が大幅に短縮されました。

2. WebKit ライブラリの問題

Rust エポックでは LTO が速いですが、Zig エポックでも同様の課題がありました。

  • 原因: Bun が使用する JavaScript エンジン(JavaScriptCore/WebKit)のライブラリ自体が、別のビルドからダウンロードされており、
    -flto=full
    (Full LTO)
    でコンパイルされていたためです。
  • 対策: WebKit リポジトリを再構築し、互換性のある ThinLTO 設定 に変更しました。

3. 最終的な改善結果

以下の手順(Zig の Full LTO → ThinLTO 変更 + WebKit/ICU の再ビルド)を実施した結果です。

ビルド構成全体時間 (F/L)ファイナルリンカー時間
オリジナル Zig (Full LTO)24m24s16m35s
ThinLTO + オリジナル WebKit20m20s12m55s
ThinLTO + 再構築 WebKit15m11s7m22s

4. Rust vs Zig の構造的な差

リンク処理以外の遅延要因も特定されました。

  • Rust: コードを 90 クレイスト(モジュール)以上 に分割し、並列化してコンパイルしています。
  • Zig: ビルド全体を 1 つの巨大な Zig モジュール として処理しようとしました。
  • 結果: Rust は並列化できるため速いですが、Zig は単一モジュールによるリンク処理自体がコスト高でした。

まとめ

初期ビルドでの大きな遅延は、巨大なリンカーステップ(Full LTO と WebKit の影響) に起因していました。これを解決することで、ビルド時間は 24 分から 15 分 に短縮されました。ただし、残りの 7 分のリンク処理と構造的な並列化の不足が依然として差を生んでいます。

他にも見つけた「小さな遅延」

ビルドトレースからは、最適化対象ではないものの興味深い発見もありました。

  • ネットワーク通信: IP アドレス取得などのパブリックインターネットへの問い合わせ(<1 秒)。
  • 依存関係のダウンロード: WebKit のアーカイブ ダウンロードと抽出に約 20 秒かかった場合がある。
  • コンパイラの内部: Clang の
    ModuleInlinerWrapperPass
    一つで、バックエンド作業の 4 秒以上を消費しているケースもある。

buildprof の仕組み

技術スタック

  • ptrace: Linux 固有のデバッガーインターフェースを使用。子プロセスのフォークや
    exec
    を直接追跡可能。
  • seccomp: ファイルシステム活動において、必要な呼び出しのみをインターセプトしてオーバーヘッドを抑制します。
  • UI: Perfetto UI のソフトフォークです。録画データをブラウザで開き、プロセスツリーやファイルの流れを可視化できます。

オーバーヘッドの例

対象未追跡 (秒)追跡時 (秒)オーバヘッド
ripgrep / Cargo12.2712.30僅か
Redis / Make26.7831.89*約 5 秒 (ファイル操作多)

*ファイルシステム追跡をオフにするには

--no-file-events
オプションを使用します。

類似ツールとの比較

既存のツールの限界が明らかになり、buildprof を開発した動機となりました。

ツール名特徴・制限点
ninjatracingNinja ログのみ解析。サブプロセス全体や上位スクリプトを一つのブロックとして表示するため、詳細が見えない。
Cargo timingsCargo 管理部分しか見えず、ビルドスクリプト全体(例:Bun の 5m40s のうち 1m51s)をカバーできない。
-ftime-trace (Clang)コンパイラ内部の詳細はわかるが、ビルド全体の文脈やコンパイラ自体の理解には不十分。
strace / tracexecプロセスイベント全体を表示するが、ビルド特有の依存関係や順序の可視化がない。
What The Fork (via)プロセス追跡に近いが、現在プライベートベータ版でオープンソース化なし。

今後の計画と結論

buildprof はすでに期待した成果を上げましたが、以下の点での改善を目指しています。

  • 記録オーバーヘッドの低減: 特に多数のファイルを扱うビルド(Redis など)への最適化。
  • OS 拡張: macOS への対応検討、Windows へのサポート要望受付。
  • より多くのツールチェーン対応: npm、Gradle、Bazel などのテスト実施。
  • クリティカルパスの自動特定: 手動での依存関係追跡から、ビルドを妨げるチェーンを自動的に注釈付ける機能へ。

結論:
buildprof は「ビルドが遅い理由」を可視化し、根本原因(例:LTO 設定、外部ライブラリのコンパイル方法)へのアプローチを可能にしました。次回ビルドが遅くなった際は、ぜひ

buildprof
を使って原因を探ってみてください!

同じ日のほかのニュース

一覧に戻る →

2026/09/13 1:25

OpenStreetMap に最初の変更を加える

## Japanese Translation: OpenStreetMap は、近隣の店舗や施設に公式ウェブサイトのタグを追加することで、有意義な貢献を誰もが求めるよう呼びかけています。この作業は 15 分以内で完了可能です。この単純な行動は、米国だけで 100 万を超える店舗が存在するにもかかわらず、アクティブなマッパーの数はそれに比べて遥かに少ないという重要なデータギャップに対処しています。既存のエントリの多くはこの不可欠なウェブ住所を欠いています。無料の JOSM エディタと、そのウェブサイトウィザードプラグインを活用することで、貢献者は不足しているタグを効率的に特定できます。単一のウェブサイトタグを追加するだけで、マッピングソフトウェアは電話番号、営業時間、メールアドレスなどの重要な詳細情報を自動的に推測でき、世界中で利用可能な多数の無料サービスへのデータ提供を強化します。著者は、シアトルのウォリングフォード地区で 1 つのチェンジセット内にて 66 の新規タグを追加するだけでその影響を実証しました。結局のところ、これらのツールの普及啓発は、誰でも無料で利用できるより完全なデジタル地図の構築に貢献します。 ## Text to translate: The original summary is high quality and well-balanced, so it does not require improvement. ## Summary: OpenStreetMap invites everyone to make a meaningful contribution by adding official website tags to nearby shops or amenities—a task achievable in under fifteen minutes. This simple action addresses a critical data gap, especially given that the U.S. alone hosts over one million shops while active mappers are far fewer; many existing entries lack these crucial web addresses. Using the free JOSM editor and its Website Wizard plugin, contributors can efficiently locate missing tags. Adding a single website tag automatically enables mapping software to infer other vital details like phone numbers, opening hours, and emails, enriching data for dozens of free services worldwide. The author demonstrated this impact by adding sixty-six new tags in Seattle's Wallingford neighborhood in one changeset. Ultimately, spreading awareness of these tools helps build a more complete digital map for everyone to use at no cost.

2026/09/13 5:25

Real-SWE:AI モデルを実際の企業コードベースでの運用におけるベンチマーク評価

## Japanese Translation: 2026年9月、新しい Real-SWE ベンチマークが、実際の企業からライセンスされた私有のリアルワールドエンタープライズコードベースにおいて、最先端 AI モデルに挑戦する。これに対し、以前の公衆インターネットデータを用いた評価では約 99% のトークンが隠されていたが、このベンチマークでは課題は孤立したサンドボックスから直接verbatim またはインスピレーションを得られた形で抽出されており、ここでは機密生産コードとビジネス結果への影響シナリオ(例:請求書、税金、移行)が含まれる。評価はモデル単体ではなく、モデルおよびハーネスの組み合わせを測定しており、エンタープライズエンジニアの実際の作業方法を反映している。解決率は、各課題につき 8 回の独立したランにわたる pass@1 の平均値として量化され、95% 信頼区間が示される。 タスクは平均して短く、中位値では約 1,742 文字であり、Terminal-Bench よりもはるかに短いが、DeepSWE や FrontierCode よりも長い。各参考ソリューションは通常、中位値で約 11 ファイルを編集する。性能には大きなばらつきがある:上位の解決率には Fable 5.1(38.8%)、GPT-6 AstraCodex CLI(33.8%)、Gemini 3.8 FlashGemini CLI(31.2%)、GLM 5.3Claude Code(28.8%)、Gro k 4.6Grok Build/Muse Spark 1.3Muse Code(23.8%)が含まれる。モデルは短いロールアウトでも苦戦する:約 71% のロールアウト(10 分未満)が失敗したのに対し、より長いロールアウトでは約 73% が失敗しており、最も一般的な失敗モードは要件の欠落であり、どのモデルもすべての課題を解決することはできない。 展開コストもモデルによって大きく異なる:選択するモデルによっては約 2.50 ドルから 6.96 ドル程度で変動し(Gemini 3.8 Flash は下限、Fable 5.1 は上限)、一部のモデルでは報告されていない高いコストが発生する可能性もある。この変化により、エンタープライズエンジニアは、標準的な公衆データベンチマークではほとんど準備がなされない制限された環境において、複雑な固有のパターンとビジネスリスクをナビゲートすることになる。

2026/09/09 10:57

Apple iPod エングレーバー(2019)

## 日本語翻訳: 2005 年、Apple のエンジニアは「iPod のパーソナライズ」ウェブページを革新し、巧妙な回避策を用いて静的フォームをインタラクティブなショッピングツールへと変換しました。このアップグレード以前には、顧客はカスタム製品を表示することなく、単なるテキスト入力を記入するしかできませんでした。これを解決するために、開発者は JavaScript を用いて JPEG 画像を切り替え、ユーザーがデバイスを実時間で視覚化できるようにする回転する iPod アニメーションを作成しました。また、ユーザーがタイプしたテキストに基づいてエンベージングオーバーレイを動的に生成する ImageMagick ソフトウェアを採用し、顧客が製品上に自分の名前が表示される様子を正確にプレビューできるようになりました。さらに、CSS クラスの切り替えによって古典的な黄色いフェード効果をシミュレートし、出荷見積もりに対する動的なフィードバックを提供しました。これらの手法は早期ブラウザ技術の深刻な制限に依存していましたが、顧客体験を向上させる能力においてほぼ魔法のように感じられました。この歴史的プロトタイプは、限られた技術的手段であっても、ウェブイノベーションが製品のカスタマイズ性を大幅に改善し、購入前のバイヤーの信頼性を高め、将来的なインタラクティブ電子商取引デザインのための基準を設定できることを証明しました。

Bun のコンパイル時間を理解するためのビルド可視化工具を作成しました | そっか~ニュース