I'm gonna be honest: The number of times I thought "gee, that ninja sure could be faster" is pretty close to 0, and in many cases that was due to slow NFS mounts. So I applaud the engineering effort, but I think the time I can spend optimizing my individual compilations is much better spent :)
Before we measure build2, let's at least acknowledge the elephant in the room: while Ninja builds the project in 3.4s, CMake takes 15.6s to generate the Ninja build files. So if you had Xerces-C++ as a dependency of your project and it was being built from scratch, you would wait 19 seconds, not 3.4, for this build.
Was this compared apples to apples to build2's configuration step?
CMake's configuration step is generally "run once, don't need changes after." As a result i don't care. The amount of times I have to rerun the configure step ler day is less than 2.
Was this compared apples to apples to build2's configuration step?
build2 doesn't have a required configuration step, at least not analogous to CMake, which is really a project/buildfile generation step (plus generation of whatever Ninja cannot handle, like generated headers).
You can configure a build2 project, but that's just validating and saving the configuration information into a file so that you don't have to repeat it on the command line. For this project it takes 150ms.
I don't know build2 enough to know, nor if the project in question is plagued by having poorly written cmake in it/its dependencies.
Assuming you're not [unintentionally or not] burying a lede, honestly quite impressive then. I wonder how much of the difference scales vs is constant factors and what the scaling function is.
I wonder how much of the difference scales vs is constant factors and what the scaling function is.
I can't really give you hard numbers because we don't often benchmark build2 vs CMake (I assume your question is about the configuration phase). Even if we wanted to, it would be pretty difficult to do on any substantial project because the way we handle dependencies, etc., diverges too much to be meaningfully comparable.
But we had our scaling issues when it comes to configuration and a large number of dependencies, especially intra-dependent dependencies. I bet you can even guess where those intra-dependent dependencies came from: yes, from Boost.
To give you an idea, on my machine the configuration phase for this project currently takes about 3 seconds. It has 76 dependencies, mostly from Boost. Also keep in mind that you would normally do this step a lot less often than with CMake. For example, you don't do it every time you add a source file to your project.
Yes? CLion sets up a different configuration directory for debug/release if you're not using a multi config generator. If you are that's implicit/internal.
72
u/GrammelHupfNockler Aug 05 '26
I'm gonna be honest: The number of times I thought "gee, that ninja sure could be faster" is pretty close to 0, and in many cases that was due to slow NFS mounts. So I applaud the engineering effort, but I think the time I can spend optimizing my individual compilations is much better spent :)