Re: [PATCH 01/02/RFC] implement a stat cache
- From
- Luciano Rocha <luciano@eurotux.com>
- Date
- Apr 20, 2008, 22:04 UTC
- Message-ID
- <20080420215700.GA18626@bit.office.eurotux.com>
- In-Reply-To
- <alpine.LFD.1.10.0804200836310.2779@woody.linux-foundation.org>
On Sun, Apr 20, 2008 at 09:03:13AM -0700, Linus Torvalds wrote:
Show 9 quoted lines
> > > On Sun, 20 Apr 2008, Luciano Rocha wrote: > > > > 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.
Show 13 quoted lines
> 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 <luciano@eurotux.com> Eurotux Informática, S.A. <http://www.eurotux.com/>