エージェント、サンドボックス、人間によるTurborepoの96%高速化

私は、ベンチマーク作業の全ワークフローを自動化するbashスクリプトを作成しました。以下は完全なGistの要約版です。 このスクリプトの最後で、プロファイルを自分のラップトップにダウンロードしていることに気づくでしょう。これにより、私のエージェントはベンチマーク結果とMarkdownプロファイルをローカルで検査し、変更が真の改善なのかノイズなのかを確信を持って判断できるようになりました。 壁を突破する サンドボックスからのクリーンなシグナルにより、ノイズの多い私のラップトップ環境では見えなかった、低レベルの変更による真の突破口を確認できました。 スタック割り当てgit OID（#11984） gitインデックス内のすべてのファイルは、その40文字のSHA-1ハッシュをヒープ割り当てされた文字列（String）として保存していました。私たちの最大のリポジトリでは、`new_from_gix_index` の呼び出しだけで、10,000個以上の個別の40バイトのヒープ割り当てが発生していました。 `OidHash` は `Deref ` を実装しているため、既存の利用者は変更を意識せずに済みます。また、`Copy` を実装することで、クローン作成がヒープ割り当てではなく、スタック上の40バイトのメモリコピー（memcpy）になります。プロファイルデータによると、`new_from_gix_index` の自己時間（self-time）が15%、`get_package_file_hashes_from_index` が17%減少しました。 | リポジトリサイズ | 前 | 後 | 変化 | | :--- | :--- | :--- | :--- | | ~1,000パッケージ | 1.463s ± 0.052s | 1.466s ± 0.027s | 速度は同等、分散（variance）が48%減少 | | ~125パッケージ | 658.6ms ± 144.6ms | 592.1ms ± 62.9ms | 10%高速化、分散が57%減少 | | 6パッケージ | 96.8ms ± 46.7ms | 75.0ms ± 18.4ms | 22%高速化、分散が61%減少 | 3つのサイズすべてにおいて最も注目すべき改善は、実行ごとの分散の減少です。これは、アロケータ（allocator）への負荷が軽減され、パフォーマンスがより予測可能になるという私たちの仮説と一致しています。 システムコール（syscall）の排除（#11985） すべてのキャッシュフェッチ（cache fetch）は、3つのシステムコールを実行していました: `stat(.tar)`（これは常にENOENTを返す）、次に `stat(.tar.zst)`、そして `open(.tar.zst)` です。これは奇妙なパターンでした。 調査の結果、`.tar` フォールバックは、TurborepoのGolang時代（2021-2022年）からのキャッシュアーティファクト（cache artifacts）のために存在していたことが判明しました。最新バージョンは非圧縮キャッシュエントリを書き込まず、キャッシュエントリは常にローテーション（rotate out）されます。 最大のリポジトリにおける962回のキャッシュフェッチ全体で、フェッチの自己時間は200.5msから129.6msに減少し、35%の削減となりました。 クローン（clone）ではなくムーブ（move）（#11986） ビジター（visitor）のディスパッチループ（dispatch loop）は、事前計算されたマップから、約1,700のタスクそれぞれに対して `(String, HashMap )` をディープクローン（deep-cloning）していました。各タスクIDはディスパッチストリームに正確に一度だけ現れるため、`HashMap::remove()` を使ってクローン作成ではなく、コストゼロで値をムーブアウト（move the value out）することが可能です。 結果 8日後、最大のリポジトリにおける初回タスクまでの時間（Time to First Task）は8.1秒から716ミリ秒に減少しました。 | リポジトリサイズ | v2.8.0 | v2.9.0 | 改善 | | :--- | :--- | :--- | :--- | | ~1,000パッケージ | 8.1s | 0.716s | 91%高速化 | | 132パッケージ | 1.9s | 0.361s | 81%高速化 | | 6パッケージ | 0.676s | 0.132s | 80%高速化 | エージェントなしでは、これには少なくとも2ヶ月はかかったと推定しています。しかし、この記事が、エージェントが私の代わりに仕事をしたわけではないことを示してくれればと思います。私は常に主導権を握り、何をプロファイリングするか、どの提案を追求するか、いつツールを変更するか、いつ戦略を転換するかを決定していました。私の既存のエンジニアリング知識、エージェントへのより優れたツールの提供、そしてクリーンなベンチマーク環境の組み合わせにより、6ヶ月前には不可能だったペースで進めることができたのです。 Turborepo 2.9でリリース これらのパフォーマンス向上は、現在安定版で利用可能です。Turborepo 2.9のリリース投稿を訪れて、詳細を確認してください。

エージェント、サンドボックス、人間によるTurborepoの96%高速化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト