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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sun, 20 Apr 2008, Luciano Rocha wrote:
> 
> 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.

Agreed. I think a big part of the overhead is also the allocation cost, 
and that can probably be obliterated (or at least minimized) by using a 
special and much faster allocator (see "alloc.c") since none of the 
allocations will ever be free'd.

The one thing I liked about your patch was that I think we could be better 
off with wrapping "lstat()" for other reasons - the same way we wrap 
read/write calls in our own "write_in_full()" simplified library 
functions. I hate tracing them, for example, and a wrapper around lstat() 
would have helped my efforts to avoid some of the unnecessary ones.

So I do think your stat cache could be improved, but for the reasons I 
outlined I would much prefer to make it unimportant instead.

I do agree that actually actively removing stat calls requires a lot more 
subtle interactions. We almost always *have* the stat information in the 
index, but the problem with "git status ." is that we re-read the index so 
many times (and then have to re-validate the stat info).

		Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux