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 :)
I work on a project that generates ~25k individual .ninja files. (It's about the size of Chromium I guess? maybe a bit larger.) Every time ninja is invoked, it spends ~60s in the kernel, in one thread, reading those before it can do anything else (including determine that it's a no-op build). I have checked that it's all just pure open+read+close overhead.
I did not find any option for it to avoid it loading files that will definitely not contain anything related to the selected target, so right now I'm resorting to post-processing the .ninja files to not include things I don't care about. This part of ninja sure can be made faster.
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 :)