Re: [PATCH/RFC 0/6] commit caching
- From
Jeff King <peff@peff.net>
- Date
- Jan 30, 2013, 07:18 UTC
- Message-ID
- <20130130071839.GF11147@sigill.intra.peff.net>
- In-Reply-To
- <CACsJy8BE3LdxbZzdQXuvEJop23KnnLbCTgPos9CywKV7EY2q9g@mail.gmail.com>
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
Show 12 quoted lines
> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> 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?
> 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.
-Peff