On Wed, Jan 30, 2013 at 2:18 PM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote: > >> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@xxxxxxxx> wrote: >> > The timings from this one are roughly similar to what I posted earlier. >> > Unlike the earlier version, this one keeps the data for a single commit >> > together for better cache locality (though I don't think it made a big >> > difference in my tests, since my cold-cache timing test ends up touching >> > every commit anyway). The short of it is that for an extra 31M of disk >> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of >> > ~4.2s to ~0.66s. >> >> Some data point on caching 1-parent vs 2-parent commits on webkit >> repo, 26k commits. With your changes (caching 2-parent commits), the >> .commits file takes 2241600 bytes. "rev-list --all --quiet": > > Hmm. My webkit repo has zero merges in it (though it is the older > svn-based one). What percentage of the one you have are merges? How does > your 1-parent cache perform on something like git.git, where about 25% > of all commits are merges? git.git performs worse with 1-parent cache. But the point is it should be customizable. >> The performance loss in 1-parent case is not significant while disk >> saving is (although it'll be less impressive after you do Shawn's >> suggestion not storing SHA-1 directly) > > Yeah, I think moving to offsets instead of sha1s is going to be a big > enough win that it won't matter anymore. Yeah, if we use uint32_t instead of sha-1, the cache is just about 400k 2 parents for webkit, 312k for 1 parent. The total size is so small that reduction does not really matter anymore. -- Duy -- 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