Hacker News Reader

Comment by isaachier | Hacker News Reader

This benchmark would imply that isn't usually the case: http://david.rothlis.net/ninja-benchmark/.

I just converted a large project's build system from Makefiles to meson+ninja. The ninja part is significantly faster than make was because it's keeping all the processor cores busy all the time which make doesn't do.

alias mj=‘make -j $(nproc)’ works like a charm on all my CMake projects. Keeps the cores warm!

Ninja does this by default but additionally has a much lower overhead on incremental rebuilds.

you can also set MAKEFLAGS=" -j $(nproc)" and keep using `make` as your would normally

It’s nice to drop back to serial compilation when debugging IMHO. Sometimes one header bug causes two errors with interspersed output in parallel builds.

Ninja serializes each tool's output.

(I imagine it buffers the output internally. With a moment's thought you can imagine situations specifically engineered to cause more problems than this solves, but I've been using Ninja for a couple of years now and I've yet to see that happen.)

make -O does the same. In fact, it can serialize a whole target, at the cost of buffering that output.

Awesome ;) - thanks for this note. I've been using the same no-dependency no-cygwin Windows build of 3.80 for about ten years, and OS X comes with 3.81, so my GNU Make skills never got any further than that. But this has prompted me to track down a similar Windows build of GNU Make 4.21, so all I need to do now is figure out how to get one set up on OS X...

This won't get me to switch away from Ninja when using CMake, but I write my own -j-friendly makefiles sometimes, so this will come in handy.

That's a good point, but I'm debugging much less often than running make, so when I want to disable parallel builds I just `unset` the MAKEFLAGS variable. For me this is a nice default.

No, I was comparing ninja to make -j8. If you have large recursive makefiles they end up waiting for each sub-target to be made before the next directory is entered and made. This has a significant effect when compiling our ~100k line code base. Maybe 30% slower on average.

Reply on news.ycombinator.com