> The first one is a criticism of CMake, not Ninja (?), so I don't think it can be why.

Fair enough. The point I was making is that if you want to compete with Ninja, you cannot leave any potential performance gains on the table.

> The second reason given is doing some work like header dependencies in multiple threads. This is the most plausible reason to me but it still feels unlikely.

We are talking about ~2% performance difference here. Parallelizing even a small amount of work across 24 threads rather that doing it serially saving a percent or two feels plausible to me.

> There is some hand waving about file access patterns but I am skeptical; if the end-to-end build time is 3 seconds then the project is small enough to all fit in kernel caches.

It fits into the system's file cache unless there is memory pressure, like one would expect from having 24 C++ compiler jobs running in parallel. We actually measured this in isolation (with more detailed results in the linked article) and it has a measurable effect.

> They also mention doing other things like invoking the compiler to get version information. This seems like it would dwarf any performance gain from number 2.

I measured this, it costs 70ms or ~2% of the overall time.

And if they are in their own targets, they are not really an issue (they would serialize everything that depends on them as you'd expect), but if you have them in a library grouped with other files to compile, then the whole library compilation is serialized.

And obviously worse if you also have to build the generator for the generated files, but that's not a big surprise, you can observe that in full builds of Chromium or its libraries too waiting for protoc if you crank the parallelization a lot.

Would be nice to see build2 go this route.

The speed (reading the build.ninja file) was never a concern for us. If I could share a wish-list, it will be:

- Fix the possibility of a segmentation fault when the build file is damaged;

- Use a better order of execution: https://github.com/ninja-build/ninja/issues/2157

Since they had to rewrite the build file for their program I also assume that something is missing. Didn’t see any mention of verifying that.

I also really didn’t like their denigrating tone. It totally turns me off trying build2, because it seems they don’t understand the point of separating build stages like environment setup (getting dependencies), configure, native build, cross build, packaging. I am a very happy ninja user instead of a batteries-included solution because it does its one job well and can be used very flexibly. I personally detest cmake, so I use nix + own configure script + ninja.

The blog is also wrong about ninja being unable to call configure, but I intentionally don’t want that (I want the build stages to communicate in one direction for sanity).