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

From: Brian Downing <bdowning@lavos.net>
Date: Jan 20, 2008, 20:03 UTC
Message-ID: <20080120200310.GK22503@lavos.net>
In-Reply-To: <alpine.LFD.1.00.0801200942191.2957@woody.linux-foundation.org>

On Sun, Jan 20, 2008 at 10:20:46AM -0800, Linus Torvalds wrote:

Show 11 quoted lines

> 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