* 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@xxxxxxxxxxxxx>
| 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
