From: Linus Torvalds Date: Tue, 24 May 2005 06:19:49 GMT Subject: Re: [PATCH 3/3] Diff overhaul, adding the other half... Message-ID: In-Reply-To: <7vbr71xjyt.fsf@assigned-by-dhcp.cox.net> On Mon, 23 May 2005, Junio C Hamano wrote: > > I have not measured things yet, but I think the big CPU waste is > coming from either expanding all the blobs and/or running the > diff-delta on many file pairs. If that is indeed the cause, > then helping the upfront check in the similarity estimator that > refuses to consider a file pair whose file size change is too > big may be a good way to resolve this problem. Since pretty much all the blobs will be expanded in the working directory anyway, it sounds like that would be the way to go. > One approach, which I think is an unacceptable change at this > stage (but I would seriously consider if this _were_ a week and > half old project), is to record the blob size as part of the > object ID. We say object size is "unsigned long" everywhere, so > I am talking about making the object ID from 20-byte SHA1 to > 24-byte SHA1 plus 4-byte integer in the network byte order. You can actually get the blob size fairly easily for non-delta objects, by just unpacking the beginning of it. But since we have the files.. That said, I don't think -C is that important. I personally don't see it as a thing I'd run normally - it's more of a thing I might do between releases rather than for something like git-whatchanged that looks at every commit. It's an interesting thing to have _available_, but I don't think it's a huge problem if it is a lot more expensive than the more normal "-M". Linus