bazel: Touching BUILD and WORKSPACE slows down the build

https://groups.google.com/forum/#!topic/bazel-discuss/0NFvo8O9vOQ

While we’re transitioning to Bazel, we’re automatically generating our BUILD and WORKSPACE files from other sources.

I’m a bit surprised to see that the Bazel build gets a lot slower when we regenerate/touch the BUILD/WORKSPACE files, even when the files themselves are unchanged.

In this example: https://github.com/dfabulich/touch-build a clean build takes 11s, and rebuilding takes 0.2s, but if I touch BUILD it takes 1.5s, and if I touch WORKSPACE it takes 3.3s.

$ bazel clean
INFO: Starting clean (this may take a while). Consider using --expunge_async if the clean takes more than several minutes.
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 11.058s, Critical Path: 7.72s
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 0.167s, Critical Path: 0.00s
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 0.153s, Critical Path: 0.00s
$ touch BUILD
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 1.546s, Critical Path: 0.19s
$ touch BUILD
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 1.562s, Critical Path: 0.19s
$ touch WORKSPACE
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 3.281s, Critical Path: 1.75s
$ touch WORKSPACE
$ bazel build //:x
INFO: Found 1 target...
Target //:x up-to-date:
  bazel-bin/libx.jar
INFO: Elapsed time: 3.296s, Critical Path: 0.23s

About this issue

  • Original URL
  • State: open
  • Created 8 years ago
  • Comments: 31 (30 by maintainers)

Most upvoted comments

I was very surprised about this behavior, not just because it reevaluates when mtime changes, but also for e.g. whitespace changes.

BUILD and rules bazel files seem to be extremely clever about when they invalidate, based on whether the actions themselves change. WORKSPACE rules could at least hash over a normalized AST representation (without comments) to make constant refactoring feasible. The framework to do that is already in place after all.