Re: [PATCH 3/3] Diff overhaul, adding the other half...

From: Linus Torvalds <torvalds@osdl.org>
Date: May 24, 2005, 06:19 UTC
Message-ID: <Pine.LNX.4.58.0505232314510.2307@ppc970.osdl.org>
In-Reply-To: <7vbr71xjyt.fsf@assigned-by-dhcp.cox.net>

On Mon, 23 May 2005, Junio C Hamano wrote:

Show 7 quoted lines

> 
> 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.

Show 6 quoted lines

> 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