The Cost of Downgrading Build Systems: A Case Study of Kubernetes

• URL: http://arxiv.org/abs/2510.20041v1
• Date: Wed, 22 Oct 2025 21:40:23 GMT
• Title: The Cost of Downgrading Build Systems: A Case Study of Kubernetes
• Authors: Gareema Ranjan, Mahmoud Alfadel, Gengyi Sun, Shane McIntosh,
• Abstract summary: We study a project that downgraded from an artifact-based build tool (Bazel) to a language-specific solution (Go Build)<n>We find that Bazel builds are faster than Go Build, completing full builds in 23.06-38.66 up to 75.19.<n>Downgrading from Bazel can increase CI resource costs by up to 76.
• Score: 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

Related papers

• Understanding and Detecting Flaky Builds in GitHub Actions [6.3850400710838615]
  We present a large-scale empirical study of flaky builds in GitHub Actions based on rerun data from 1,960 Java projects.<n>We identify 15 distinct categories of flaky failures, among which flaky tests, network issues, and dependency resolution issues are the most prevalent.<n>We propose a machine learning-based approach for detecting flaky failures at the job level.
  arXiv  Detail & Related papers  (2026-02-02T16:39:56Z)
• Can Language Models Go Beyond Coding? Assessing the Capability of Language Models to Build Real-World Systems [44.748487030119]
  Large language models (LLMs) have shown growing potential in software engineering.<n>Few benchmarks evaluate their ability to repair software during migration across instruction set architectures (ISAs)
  arXiv  Detail & Related papers  (2025-11-02T03:23:07Z)
• ToolLibGen: Scalable Automatic Tool Creation and Aggregation for LLM Reasoning [80.10274552177096]
  Large Language Models (LLMs) equipped with external tools have demonstrated enhanced performance on complex reasoning tasks.<n>The widespread adoption of this tool-augmented reasoning is hindered by the scarcity of domain-specific tools.<n>We propose a systematic approach to automatically an unstructured collection of tools into a structured tool library.
  arXiv  Detail & Related papers  (2025-10-09T04:11:16Z)
• Attestable builds: compiling verifiable binaries on untrusted systems using trusted execution environments [3.207381224848367]
  attestable builds provide strong source-to-binary correspondence in software artifacts.<n>We tackle the challenge of opaque build pipelines that disconnect the trust between source code and the final binary artifact.
  arXiv  Detail & Related papers  (2025-05-05T10:00:04Z)
• Causes and Canonicalization for Unreproducible Builds in Java [11.155099138622148]
  We introduce a conceptual framework for reproducible builds, analyze a large dataset from Reproducible Central, and develop a novel taxonomy of six root causes of unreproducibility.<n>We present Chains-Rebuild, a tool that achieve successfulcanonicalization for 26.60% on 12,803 unreproducible artifacts.
  arXiv  Detail & Related papers  (2025-04-30T14:17:54Z)
• Thinking Slow, Fast: Scaling Inference Compute with Distilled Reasoners [72.37408197157453]
  Recent advancements have demonstrated that the performance of large language models (LLMs) can be significantly enhanced by scaling computational resources at test time.<n>This raises a fundamental question: can models with lower complexity leverage their superior generation throughput to outperform similarly sized Transformers for a fixed computational budget?<n>To address this question and overcome the lack of strong subquadratic reasoners, we distill pure and hybrid Mamba models from pretrained Transformers.
  arXiv  Detail & Related papers  (2025-02-27T18:08:16Z)
• Buffer of Thoughts: Thought-Augmented Reasoning with Large Language Models [65.48185395952788]
  Buffer of Thoughts (BoT) is a novel and versatile thought-augmented reasoning approach. We propose meta-buffer to store a series of informative high-level thoughts. For each problem, we retrieve a relevant thought-template and adaptively instantiate it with specific reasoning structures.
  arXiv  Detail & Related papers  (2024-06-06T17:22:08Z)
• Does Using Bazel Help Speed Up Continuous Integration Builds? [9.098224117917336]
  New artifact-based build technologies like Bazel have built-in support for advanced performance optimizations. We collected 383 Bazel projects from GitHub, studied their parallel and incremental build usage of Bazel in 4 popular CI services, and compared the results with Maven projects. Our results show that 31.23% of Bazel projects adopt a CI service but do not use it in the CI service, while for those who do use Bazel in CI, 27.76% of them use other tools to facilitate Bazel's execution.
  arXiv  Detail & Related papers  (2024-05-01T18:16:38Z)
• Detecting Build Dependency Errors in Incremental Builds [13.823208277774572]
  We propose EChecker to detect build dependency errors in the context of incremental builds. EChecker automatically updates actual build dependencies by inferring them from C/C++ pre-processor directives and Makefile changes from new commits. EChecker increases the build dependency error detection efficiency by an average of 85.14 times.
  arXiv  Detail & Related papers  (2024-04-20T07:01:11Z)
• Is Self-Repair a Silver Bullet for Code Generation? [68.02601393906083]
  Large language models have shown remarkable aptitude in code generation, but still struggle to perform complex tasks. Self-repair -- in which the model debugs and repairs its own code -- has recently become a popular way to boost performance. We analyze Code Llama, GPT-3.5 and GPT-4's ability to perform self-repair on problems taken from HumanEval and APPS.
  arXiv  Detail & Related papers  (2023-06-16T15:13:17Z)
• On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
  We present a novel approach to detect vulnerable clones in the Maven repository. We retrieve over 53k potential vulnerable clones from Maven Central. We detect 727 confirmed vulnerable clones and synthesize a testable proof-of-vulnerability project for each of those.
  arXiv  Detail & Related papers  (2023-06-08T20:14:46Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.