Re: [PATCH 01/02/RFC] implement a stat cache

On Sun, Apr 20, 2008 at 09:03:13AM -0700, Linus Torvalds wrote:

On Sun, 20 Apr 2008, Luciano Rocha wrote:

quoted

That's a lot. Why not use a stat cache?

Well, the thing is, the OS _does_ a stat cache for us, and the one that 
the OS maintains is a lot better, in that it works across processes and is 
coherent with other processes changing things.

Sure. I am even unsure if the cache didn't break any sanity check (did a
file change after ...? Did someone chdir(2)?).

And the thing is, your stat cache makes the *common* cases slower. I 
didn't do a whole lot of testing, but on my machine, doing just a "git 
status" with and without your stat cache shows

<snip>

Well, it can be improved. The memcpy can be avoided by using the stored
data directly, and a _or_die can be added for the common case.

Now, admittedly, I also do think that we should generally optimize the 
slow cases more than we should care about things that are already very 
fast, so I do not think that it's wrong to say "ok, let's make the really 
fast case a bit slower, in order to not be so slow in the bad case", so in 
that sense I do not think the slowdown is disastrous.

BUT. 

I really dislike adding a cache that is there just because we do something 
stupid. We can fix the over-abundance of lstat() calls by just being 
smarter. And the smarter we are, the less the cache will help, and the 
more it will hurt. Which is the real reason why I think the cache is a 
really really bad idea: it optimizes for the wrong kind of behavior.

I agree completly. If we can reduce the number of (l)stat calls to a
single one per file, then we'll all be happier. But that kind of change
is beyond my current understanding of git internals. ;)

Regards,
Luciano Rocha

-- 
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>