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()?
> performance gain from this patch.
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.
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?
-- Hannes
--
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
