4 ms·

The OP is 100% right that ninja's biggest architectural insight is the "assembler" metaphor. I came to this same conclusion in https://lwn.net/Articles/706404/

The OP is 100% right that ninja's biggest architectural insight is the "assembler" metaphor. I came to this same conclusion in https://lwn.net/Articles/706404/ https://lwn.net/Articles/706404/ Sad to hear the overall experience has been so negative for him. Ninja has certainly had a large impact! I can relate to the open-source burnout, even though I've experienced only a tiny tiny fraction of it compared to the success of Ninja. Re. speed, I wonder how much of Ninja's speed over make is thanks to Ninja's "deps log" binary format. In my (fabricated) benchmarks, Make spent 98% of its time processing the compiler-generated ".d" files that are used to track dependencies on header files: https://david.rothlis.net/ninja-benchmark/ https://david.rothlis.net/ninja-benchmark/

evmar 6y ago
Ninja originally used `.d` files as well (it was built while incrementally replacing a make-based system so it did many things like make). My recollection is that it was already faster than make without the deps log, but it is almost certainly project specific, and perhaps due to the ways we were abusing make (search for "clever hacks" on http://neugierig.org/software/chromium/notes/2011/02/ninja.html http://neugierig.org/software/chromium/notes/2011/02/ninja.h... for some discussion of this. With that said, the deps log processing of .d files was a huge win for us. One thing to observe is that it's the same code and amount of work either way, but if you load them at startup they are processed during the critical path, while the deps log parsing happens during the build so their cost is amortized.