Re: [PATCH 3/5] combine-diff: handle binary files as binary
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 30, 2011, 19:32 UTC
- Message-ID
- <7vipssm1bb.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110530161927.GC24431@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> git log -p --cc --merges origin/master > > on git.git using both v1.7.5.3 and the jk/combine-diff-binary-etc > branch. And it turns out that the extra loads really don't make a > difference in practice. My best-of-5 for the two cases were:
I am not surprised. git.git is small enough and developer machines these days are beefy enough so that most of the data from the disk are sitting in the buffer cache, and if you are well packed and Linus's law "a file always grows" holds true, it is likely that you are also benefiting from the delta-base cache, as the history traversal of the command goes newer to older.
> $ time git.v1.7.5.3 log -p --cc --merges origin/master >/dev/null > real 0m59.518s > user 0m58.672s > sys 0m0.688s
Comparing that with the run time of the same log without patch generation would roughly give the cost of "all text combined" diff. I suspect more than 90% of the time goes to running the textual diff algorithm.
I guess you are hinting that we should optimize that part before worrying about the wastage of reading these blobs always twice.