He should probably look at tup (http://gittup.org/tup/make_vs_tup.html) which, when using inotify (otherwise stat must be called O(n) times), pretty much always start building (or reports nothing to do) in a few milliseconds.
Thanks for reminding me of tup again. I read about it earlier, and had always meant to go back to it and give it a try.
And I wonder whether we can make a version of git that uses inotify.
If he's willing to endure a long-lived server process, he can probably have no-op builds with a tup-like system in less than a few milliseconds. (Basically as long as it takes to run through a single `if' and return to the shell; since no news is good news.)
See also http://gittup.org/tup/tup_vs_mordor.html which compares tup to "the All-Seeing Eye of Mordor". Not an actual build system, alas, but a hypothetical perfect one that Just Knows what files need rebuilding and rebuilds them with no overhead.
It turns out (not terribly surprisingly, given how it works) that tup's overhead is very small.
He decided that inotify wasn't worth it for his purposes.
> I had originally intended to make Ninja be memory-resident and to use inotify to keep the build state hot at all times. But upon writing the code I found it was fast enough to run from scratch each time. Perhaps a slower computer would still benefit from inotify; the data structures are set up such that using inotify shouldn’t be hard.
