fscache: add not-found directory cache to fscache

[jeffhostetler]

Teach FSCACHE to remember "not found" directories.

This is a performance optimization.

FSCACHE is a performance optimization available for Windows. It
intercepts Posix-style lstat() calls into an in-memory directory
using FindFirst/FindNext. It improves performance on Windows by
catching the first lstat() call in a directory, using FindFirst/
FindNext to read the list of files (and attribute data) for the
entire directory into the cache, and short-cut subsequent lstat()
calls in the same directory. This gives a major performance
boost on Windows.

However, it does not remember "not found" directories. When STATUS
runs and there are missing directories, the lstat() interception
fails to find the parent directory and simply return ENOENT for the
file -- it does not remember that the FindFirst on the directory
failed. Thus subsequent lstat() calls in the same directory, each
re-attempt the FindFirst. This completely defeats any performance
gains.

This can be seen by doing a sparse-checkout on a large repo and
then doing a read-tree to reset the skip-worktree bits and then
running status.

This change reduced status times for my very large repo by 60%.

[whoisj]

Ooh, this should be a pretty decent performance improvement when using sparse. 😁

[jeffhostetler]

@dscho I pulled your fixup and added one more.

[dscho]

@jeffhostetler okay, good. Please note that the fixup! <original-oneline> format is picked up by git rebase -i --autosquash, so your latest commit will not be handled automatically...

Other than that, I think the only thing we may want to consider is to try our hand at a test that verifies somehow that non-existing directories are not accessed more than once. We could introduce a new GIT_TRACE_FSCACHE category to that end, for example, and validate its output.

What do you think?

[whoisj]

We could introduce a new GIT_TRACE_FSCACHE category to that end, for example, and validate its output.

Brilliant. The more optional tracing we enable, the easier debugging will be in the future.

[jeffhostetler]

@dscho Yeah. I'll re-title the commit and look at adding the tracing. I'll try to fix this up next week. Thanks!

[dscho]

The more optional tracing we enable, the easier debugging will be in the future.

Well, we should not overdo it, in particular in performance-critical code such as FSCache... 😄

[jeffhostetler]

In this version, I added a simple GIT_TRACE_FSCACHE key to log each time FindFirst fails.
On my very large test repository (3.1M files with a 35K sparse checkout), the number of calls
to FindFirst went from 9.1M to 450K. The size of the trace log went from 1.1GB to 55MB.

[dscho]

Excellent! I added a test that I merged, too (10b99b6).