- SourceFSは、大規模なデバイスコードベースのビルド速度と効率性の問題を解決するために設計された高性能な仮想ファイルシステム
- Androidビルド速度を最大9倍、コードチェックアウト速度を10倍以上向上させ、ディスク使用量を83%削減し、コンピューティングコストを14倍削減
- 中核原理は**ファイル仮想化とオンデマンド（materialization）**方式で、実際のファイルのように見えながら、必要な瞬間にのみ内容を読み込む構造
- ビルド過程では、入出力・環境を記録して再利用するサンドボックスベースのキャッシュを通じて、ほとんどのビルド段階を即座にリプレイ（replay）
遅いビルドとコードチェックアウトの問題
- 現代のコネクテッドデバイスは、数億行規模のコードベースで動作している
- Linuxカーネルは約4,000万行、Android AOSPは1億4,000万行以上で、実際のデバイスではハードウェア対応・カスタム機能・サービスコードが追加されて2億行を超える
- 電気自動車（EV）は5億行以上に達し、ソフトウェアアップデートによって継続的に増加
- コードチェックアウト時には数百GBのデータをダウンロードし、ビルドは数十万段階を経る
- 依存関係グラフの不完全さにより、小さな変更でも大規模な再ビルドを引き起こしたり、誤った結果を招いたりする
- その結果、毎日数時間の開発者時間の損失とCIコンピューティングコストの急増が発生
Source File System (SourceFS)
- SourceFSは新しいビルドシステムではなく、既存のワークフローに統合可能な高性能な仮想ファイルシステム
- Androidコードベースのチェックアウトおよびビルド速度を飛躍的に向上させ、移行負担がほとんどない
- 中核原理はすべてのファイルを仮想化し、必要なときだけ実体化（materialize）し、この過程を透過的に処理すること
- チェックアウト高速化: コードベース全体の仮想ファイル表現を生成し、アクセス時点でのみ内容を読み込む
- ファイルは実在するように見えるが、ほとんどのファイルは仮想状態のまま残り、ディスク容量を節約
- GitおよびRepoと完全互換
- ビルド高速化: 各ビルド段階は、入出力・環境を記録する軽量サンドボックス内で実行
- 同一段階は再実行せず結果を再利用し、変更された段階だけを新たに実行
- コンパイルだけでなく、リンク、パッケージング、ドキュメント生成などビルドプロセス全体に適用
- 内部的には高性能キャッシュ・リプレイアルゴリズム、効率的なサンドボックス化、Rustベースのバックエンドを使用
高速ビルド、効率的なストレージ、コスト削減
- SourceFS環境でのコードチェックアウトは従来比で20倍以上高速
- 開発者は従来のGitツリーと同じワークフローを維持したまま、SourceFSフォルダで作業可能
- ディスク使用量の削減は、複数のコードベースを切り替える必要があるデバイス開発者にとって大きな利点
- 複数デバイスバージョン間の切り替えや大規模なバグ修正時でも、小規模なGitHubリポジトリのように軽快に作業可能
- ビルド速度は最大9倍向上し、一般的な開発者マシンでも大規模ビルドを迅速に完了
- CIパイプラインのフィードバックループ短縮により、開発生産性を最大化
- コスト削減効果は最大14倍に達する
- 高性能マシンよりも一般的なマシンでSourceFSを使うほうが、より高速かつ低コスト
- 同じコンピューティング予算でより多くの作業を実行可能
既存代替手段との比較
- SourceFSは既存アプローチの限界を克服
- Bazel、Buck2など新しいビルドシステムへの移行は大規模プロジェクトでは現実的に難しく、複数OS（例: Yocto、Android、QNX）を含むデバイスコードベースでは複雑さが倍増
- SourceFSはそのような移行なしでも同等の性能向上を提供
- **コンパイララッパー（REClient、Gomaなど）**は一部のビルド段階しか高速化できず、チェックアウトには効果がない
- コマンドラインフラグの解析に依存するため、予期しないエラーが発生する可能性がある
今後の計画
2件のコメント
すでにAndroidで似たようなものを使っているようですね。
Hacker Newsのコメント
チームの一部は 元Google社員 出身のようだが、私たちが知っている Piper ベースの srcfs とは別物らしい
共通点はあるものの詳細がほとんどなく、セルフホスティング版 も「Talk to us」式の価格設定なのが残念
それと価格の話だけど、数十億行規模のコードベースを扱うチームなら「TalkToUs」価格くらい負担できるのでは？
Linux のようなオープンソースでさえ自分のノートPCで普通に動く
これを見て、昔の ClearCase の MVFS を思い出した
ビルド時に open(2)、getenv(3) のような呼び出しをフックして、どのツールがどの環境でどのバージョンのファイルを使ったのかをすべて記録していた
同じ条件なら既存の結果を 「winked-in」 して再利用し、ファイルシステムレベルでのバージョン管理も可能だった
たとえば file.c@@/trunk/branch/subbranch/3 のような形でアクセスできた
タイトルにある時間の数字は少し大げさに感じる
もしかして EdenFS や git fuse 系を製品化しようとしているのではと思った
「以前と同じビルド段階は自動的にスキップして結果を再利用する」という話だが、良すぎて逆に信じがたい
単なる 商用コンテンツマーケティング のように感じる。技術的な詳細がほとんどない
以前ビルドエンジニアとして働いていたときに効果的だったコツをいくつか挙げると、
tmpfs でビルドすること、大きなファイルはコピーではなく symlink/hardlink を使うこと、libeatmydata で不要な I/O を減らすこと、
そしてクロスコンパイラをうまく選ぶことなどがあった
本当に重要なのは、ビルドシステムを最適化し、変化しない中間生成物のキャッシュ をうまく行うことだ
こんにちは、Source.dev の共同創業者 Serban です
アップボートと議論に感謝します。初期スタートアップにとって、こうしたフィードバックは本当に大きな力になります
自分たちが作っているものに本当に価値があると感じてもらえてうれしいです
「SourceFS でビルド速度が 9 倍速くなる」という文句を見て笑ってしまった
ビルドが長くかかるほど 剣術の練習時間 が増えるので、遅いビルドにもそれなりの利点はある
彼らの 性能に関する主張 は、私が使ったことのある分散 Android ビルドシステムを大きく上回っている
どんな秘密のソースがあるのか気になる
ビルドが「十分に速い」水準に達すると、コードベースを理解するための苦痛を伴う作業に取り組む ビジネス上の動機 が失われる
これで 10 億行規模のコードベースへ向かう道だけが残った
説明を見る限り、Android ソース専用のように聞こえる。なぜそうなのか、他のコードベースにも適用できるのか気になる