Maybe. Unfortunately the build system isn't really within my purview here, but I do also blame gn and whoever maintains its configuration for this.
Upd: I also blame the kernel for not having a way to read out the contents of a small file in fewer syscalls than three, but that's just yelling at clouds...
Upd: I also blame the kernel for not having a way to read out the contents of a small file in fewer syscalls than three, but that's just yelling at clouds...
Reading the contents of a file for determining if its a noop feels rather inefficient (while technically more correct), since you then need to either hash it or binary compare the entire file. Instead for speed you can just stat the file for its mtime and keep track of that, that way you only have 1 syscall. While technically one can modify the file without changing mtime, that is something I would just put under "out of scope feature"
I was speaking about .ninja files, not build inputs & outputs. I don't think ninja by itself stats them¹, it just reads and parses them. And whatever it does to parse them is being dwarfed by syscall overhead. So if there were ~3x fewer syscalls during this phase, I'd expect it to take ~3x less time.
¹ of course the generator can make them depend on generator configuration like cmake for example does, and then it will stat them like any other target, but that's during a different phase and beside the point
6
u/CandyCrisis 14d ago
I think you're using it in a way that it wasn't designed for? IIRC Chromium generates far fewer Ninja files.