* Kjetil Barvik schrieb:
| And, yes, since each lstat() call cost approximately 44 microseconds
| compared to 12-16 for each lstat() on my Linux box, there was a little
^^^^^^^ fstat()?Yes, is is the fstat() call which takes 12-16 microseconds on my Linux box.
| performance gain from this patch.
* Johannes Sixt <j.sixt@viscovery.net> | This does look like a good gain. But do you have hard numbers that back | the claim? | | If you can squeeze out a 10% improvement on Linux with this patch, we | should take it, and if it turns out that it doesn't work on Windows, we | could trivially throw in an #ifdef MINGW (or even #ifdef WIN32 if Cygwin | is affected, too) that skips the fstat() optimization. | | But we really should have numbers that justify this effort.
I have been working on a long running test script latly, but then I started to play with the 'git repack' command, so it was not top priority. But, I can finish the script today, and run it while I am sleeping tonight.
| BTW, the statement from the Windows documentation was: | | "The only guarantee about a file timestamp is that the file time is | correctly reflected when the handle that makes the change is closed." | | In the case of this patch, the timestamp is queried via the handle | that made the change, and in this case special case the timestamp | could be correct nevertheless. The guarantee doesn't cover this case, | but it would be natural, and perhaps it Just Works?
Yes it could perhaps "just works". But, then I guess that when it does not work, the user would not notice it _except_ for more time used. Since I can to this:
kjetil@localhost ~/git/git $ git status # On branch lstat_fstat_v6 nothing to commit (working directory clean) kjetil@localhost ~/git/git $ touch var.c kjetil@localhost ~/git/git $ git status # On branch lstat_fstat_v6 nothing to commit (working directory clean) kjetil@localhost ~/git/git $
... I think that git will have to check the content and read each byte and do a SHA1 of the file var.c in this case (since the timestamps do not match), which is a more time and CPU hungry opperation, to decide if there is a difference inside the file or not.
And, maybe some other platform also have problems with this trick?
OK, I do the time tests and let the numbers talk.
-- kjetil