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