論文の概要: The Cost of Downgrading Build Systems: A Case Study of Kubernetes

• arxiv url: http://arxiv.org/abs/2510.20041v1
• Date: Wed, 22 Oct 2025 21:40:23 GMT
• ステータス: 翻訳完了
• システム内更新日: 2025-10-25 03:08:16.91923
• Title: The Cost of Downgrading Build Systems: A Case Study of Kubernetes
• Title（参考訳）: ビルドシステムのダウングレードコスト: Kubernetesのケーススタディ
• Authors: Gareema Ranjan, Mahmoud Alfadel, Gengyi Sun, Shane McIntosh,
• Abstract要約: アーティファクトベースのビルドツール(Bazel)から言語固有のソリューション(Go Build)に格下げしたプロジェクトについて研究する。 BazelのビルドはGo Buildよりも高速で、完全なビルドは23.06-38.66から75.19まで完了しています。 Bazelからのダウングレードは、CIリソースコストを最大76パーセント向上させる。
• 参考スコア（独自算出の注目度）: 9.25132407333504
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Since developers invoke the build system frequently, its performance can impact productivity. Modern artifact-based build tools accelerate builds, yet prior work shows that teams may abandon them for alternatives that are easier to maintain. While prior work shows why downgrades are performed, the implications of downgrades remain largely unexplored. In this paper, we describe a case study of the Kubernetes project, focusing on its downgrade from an artifact-based build tool (Bazel) to a language-specific solution (Go Build). We reproduce and analyze the full and incremental builds of change sets during the downgrade period. On the one hand, we find that Bazel builds are faster than Go Build, completing full builds in 23.06-38.66 up to 75.19 impose a larger memory footprint than Go Build of 81.42-351.07 respectively. Bazel builds also impose a greater CPU load at parallelism settings above eight for full builds and above one for incremental builds. We estimate that downgrading from Bazel can increase CI resource costs by up to 76 explore whether our observations generalize by replicating our Kubernetes study on four other projects that also downgraded from Bazel to older build tools. We observe that while build time penalties decrease, Bazel consistently consumes more memory. We conclude that abandoning artifact-based build tools, despite perceived maintainability benefits, tends to incur considerable performance costs for large projects. Our observations may help stakeholders to balance trade-offs in build tool adoption
• Abstract（参考訳）: 開発者は頻繁にビルドシステムを呼び出すので、そのパフォーマンスは生産性に影響を与える可能性がある。 現代的なアーティファクトベースのビルドツールはビルドを加速するが、以前の作業は、メンテナンスが容易な代替手段のために、チームはビルドを捨てる可能性があることを示している。 以前の研究は、ダウングレードが実行された理由を示しているが、ダウングレードの影響はほとんど未解明のままである。 本稿では、アーティファクトベースのビルドツール(Bazel)から言語固有のソリューション(Go Build)へのダウングレードに焦点を当てた、Kubernetesプロジェクトのケーススタディについて説明する。 我々は、ダウングレード期間中に変更セットの完全なビルドとインクリメンタルビルドを再現し、分析する。 一方、BazelビルドはGo Buildよりも高速で、23.06-38.66から75.19までの完全なビルドは、Go Buildの81.42-351.07よりも大きなメモリフットプリントを課している。 Bazelビルドはまた、フルビルドでは8つ、インクリメンタルビルドでは1つ以上の並列処理設定でCPU負荷を増大させる。 Bazelからのダウングレードは、Bazelから古いビルドツールにダウングレードした他の4つのプロジェクトのKubernetes研究を複製することで、私たちの観察が一般化するかどうかを、最大76パーセントのCIリソースコストを向上できると見積もっています。 ビルド時間のペナルティは減少するが、Bazelは一貫してメモリを消費する。 アーティファクトベースのビルドツールを放棄することは、保守性に恵まれているにもかかわらず、大規模なプロジェクトではかなりのパフォーマンスコストを発生させる傾向がある、と結論付けています。 私たちの観察は、ステークホルダーがビルドツールの採用におけるトレードオフのバランスを取るのに役立つかもしれない

関連論文リスト

• ToolLibGen: Scalable Automatic Tool Creation and Aggregation for LLM Reasoning [80.10274552177096]
  外部ツールを備えたLarge Language Models (LLM) は、複雑な推論タスクにおけるパフォーマンスの向上を実証している。 このツールに強化された推論が広く採用されるのは、ドメイン固有のツールが不足しているためである。 構造化ツールライブラリに非構造化ツールのコレクションを自動的に組み込むための体系的なアプローチを提案する。
  論文  参考訳（メタデータ） (2025-10-09T04:11:16Z)
• Attestable builds: compiling verifiable binaries on untrusted systems using trusted execution environments [3.207381224848367]
  attestableビルドは、ソフトウェアアーティファクトに強力なソース対バイナリ対応を提供する。 私たちは、ソースコードと最終バイナリアーティファクトの間の信頼を切断する不透明なビルドパイプラインの課題に取り組みます。
  論文  参考訳（メタデータ） (2025-05-05T10:00:04Z)
• Causes and Canonicalization for Unreproducible Builds in Java [11.155099138622148]
  再現可能なビルドの概念フレームワークを導入し,再現可能な中央からの大きなデータセットを分析し,再現不可能な6つの根本原因の新たな分類法を開発した。 12,803個の再現不可能なアーティファクトに対して26.60%のカノニゼーションを実現するツールであるChains-Rebuildを紹介する。
  論文  参考訳（メタデータ） (2025-04-30T14:17:54Z)
• Thinking Slow, Fast: Scaling Inference Compute with Distilled Reasoners [72.37408197157453]
  近年の進歩により、大規模言語モデル(LLM)の性能は、テスト時に計算資源をスケーリングすることで大幅に向上することが示されている。 複雑性が低いモデルは、より優れた生成スループットを活用して、固定された計算予算のために同様の大きさのトランスフォーマーを上回りますか? この問題に対処し、強い四分法的推論器の欠如を克服するために、事前訓練された変換器から純およびハイブリッドのマンバモデルを蒸留する。
  論文  参考訳（メタデータ） (2025-02-27T18:08:16Z)
• Buffer of Thoughts: Thought-Augmented Reasoning with Large Language Models [65.48185395952788]
  Buffer of Thoughts (BoT) は、斬新で多目的な思考補足的推論手法である。 そこで我々はメタバッファーを提案し,一連の情報的高レベルの思考を記憶する。 各問題に対して、関連する思考タイミングを検索し、特定の推論構造で適応的にインスタンス化する。
  論文  参考訳（メタデータ） (2024-06-06T17:22:08Z)
• Does Using Bazel Help Speed Up Continuous Integration Builds? [9.098224117917336]
  Bazelのような新しいアーティファクトベースのビルド技術は、高度なパフォーマンス最適化をサポートする。 GitHubから383のBazelプロジェクトを収集し、人気の高い4つのCIサービスでBazelの並列およびインクリメンタルビルド使用状況を調査し、結果をMavenプロジェクトと比較しました。 私たちの結果は、Bazelプロジェクトの31.23%がCIサービスを採用しているが、CIサービスには使用していないことを示している。
  論文  参考訳（メタデータ） (2024-05-01T18:16:38Z)
• Detecting Build Dependency Errors in Incremental Builds [13.823208277774572]
  インクリメンタルビルドのコンテキストにおいて、ビルド依存性のエラーを検出するためにECheckerを提案する。 ECheckerは、C/C++プリプロセッサディレクティブと新しいコミットからのMakefile変更を推論することで、実際のビルド依存関係を自動的に更新する。 ECheckerはビルド依存性のエラー検出効率を平均85.14倍に向上させる。
  論文  参考訳（メタデータ） (2024-04-20T07:01:11Z)
• Is Self-Repair a Silver Bullet for Code Generation? [68.02601393906083]
  大規模な言語モデルは、コード生成において顕著な適性を示しているが、それでも複雑なタスクを実行するのに苦労している。 自己修復(Self-repair) — モデルが自身のコードをデバッグし、修復する — は、最近、パフォーマンスを向上する一般的な方法になっている。 我々は,Code Llama, GPT-3.5, GPT-4によるHumanEvalとAPPSの自己修復能力について分析した。
  論文  参考訳（メタデータ） (2023-06-16T15:13:17Z)
• On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
  Mavenリポジトリで脆弱性のあるクローンを検出するための新しいアプローチを提案する。 Maven Centralから53万以上の潜在的な脆弱性のあるクローンを検索します。 検出された727個の脆弱なクローンを検出し、それぞれに検証可能な脆弱性証明プロジェクトを合成する。
  論文  参考訳（メタデータ） (2023-06-08T20:14:46Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。