Build systems convert source code into deliverables. Since developers invoke builds frequently, the performance of build systems 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 downgrade of build tools in the Kubernetes project, focusing on its downgrade from an artifact-based build tool (Bazel) to a language-specific solution (Go Build). We use 3,402 computational hours–equivalent to over four months of continuous experimentation–to 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 % less time and incremental builds in up to 75.19 % the other hand, Bazel builds impose a larger memory footprint than Go Build of 81.42–351.07 % and incremental builds, 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 % replicating our Kubernetes study on the 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 support more informed decision-making about build tool adoption and can help stakeholders to balance trade-offs, such as build maintainability and efficiency.