On Mon, Apr 2, 2012 at 09:49, Martin Fick <mfick@xxxxxxxxxxxxxx> wrote: > On Monday, April 02, 2012 10:39:59 am Shawn Pearce wrote: >> On Mon, Apr 2, 2012 at 09:24, Martin Fick > <mfick@xxxxxxxxxxxxxx> wrote: >> > On Saturday, March 31, 2012 04:11:01 pm René Scharfe > wrote: >> Git can't really do the same thing as "cache the >> RevWalk". Its spawning a new process that needs to >> decompress and parse each commit object to determine its >> timestamp so the commits can be sorted into the priority >> queue. This is still an O(N) operation given N >> references. > > While I suspect this has been suggested before, an ondisk > cache of commits to timestamps would probably help here with > large repos. Such a cache could make even new processes > able to create this list much quicker. Since this cache > would contain immutable data, even if it is out of date it > would likely provided significant improvements by providing > most of the timestamps leaving only a few to parse from > newer commits? Probably. But we tend to hate caches in Git because they can get stale and need to be rebuilt, and are redundant with the base data. The mythical "pack v4" work was going to approach this problem by storing the commit timestamps uncompressed in a more machine friendly format. Unfortunately the work has been stalled for years. -- 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