Re: [PATCH] Avoid running lstat(2) on the same cache entry.

[bdowning@lavos.net (Brian Downing)]

On Sun, Jan 20, 2008 at 10:20:46AM -0800, Linus Torvalds wrote:
> But I guess that was a bit optimistic. On Linux, we still had about 50% 
> user time, and I guess the same is _largely_ true on Windows. Cutting the 
> system time in half only gives you about a quarter performance 
> improvement, and I was just incorrect in expecting system calls to be the 
> limiting factor.
> 
> [...]
> 
> fnmatch? It's certainly visible on Linux, I wonder if the Windows/OSX 
> version is more expensive due to trying to be case-insensitive or 
> something?

Windows (msys) Git, with the lstat patch and on my 15433-file test case,
is at least 90-95% system time.  I don't have any good tools for
measuring this, but just using the silly performance monitor you get
with ctrl-alt-del and enabling the "View -> Show Kernel Times" curve on
the graph shows this fact pretty clearly.

I think this shows that:

1. There's not much overhead in msysGit's stat wrapper at all.  It gets
   converted quite efficiently to native Windows calls.

2. Windows really sucks at filesystem ops.  Film at 11.

One thing I dimly recall is that the nightmare interface of
FindFirstFile/FindNextFile (which I assume is what is actually getting
called for opendir/readdir) actually returns some stat information with
each file.  Would it be possible to use that directly in some cases
rather than taking an extra stat call to get it?

-bcd