On Sun, Apr 20, 2008 at 09:03:13AM -0700, Linus Torvalds wrote: > > > 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. > 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@xxxxxxxxxxx> Eurotux Informática, S.A. <http://www.eurotux.com/>
Attachment:
pgpThhKCBhEqd.pgp
Description: PGP signature
