3 ms·

He should probably look at tup (http://gittup.org/tup/make_vs_tup.html http://gittup.org/tup/make_vs_tup.html) which, when using inotify (otherwise stat must be

He should probably look at tup (http://gittup.org/tup/make_vs_tup.html 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.

eru 16y ago
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.)
- tonfa 16y ago
  You can definitely make a version of git that uses inotify (mercurial has been doing it since a couple of years).
  - eru 16y ago
    Thanks. I wasn't aware of that mercurial extension.
gjm11 16y ago
See also http://gittup.org/tup/tup_vs_mordor.html 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.
onedognight 16y ago
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.
MikeGerott 16y ago
Wow! Thanks for sharing it. 0.1 sec to recompile 100K files project. It looks really impressive.

eru 16y ago

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.)

tonfa 16y ago
You can definitely make a version of git that uses inotify (mercurial has been doing it since a couple of years).
- eru 16y ago
  Thanks. I wasn't aware of that mercurial extension.

gjm11 16y ago

See also http://gittup.org/tup/tup_vs_mordor.html 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.

onedognight 16y ago

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.

MikeGerott 16y ago

Wow! Thanks for sharing it. 0.1 sec to recompile 100K files project. It looks really impressive.