Re: [RFC] Cache negative delta pairs

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 29, 2006, 21:04 UTC
Message-ID: <Pine.LNX.4.64.0606291352110.12404@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0606291616480.1213@localhost.localdomain>

On Thu, 29 Jun 2006, Nicolas Pitre wrote:

Show 6 quoted lines

> 
> The negative delta cache concept is certainly attractive even for normal 
> repositories, especially for public servers, since when used in 
> conjonction with delta reuse it makes the creation of a pack basically 
> free.  So I think this idea really has merits, as long as the cache 
> remains small.

I don't really see much of a point of this all.

Instead of having a separate cache, wouldn't it be much better to just take the hint from the previous pack-file?

In the repacking window, if both objects we are looking at already came from the same (old) pack-file, don't bother delta'ing them against each other.

That means that we'll still always check for better deltas for (and against!) _unpacked_ objects, but assuming incremental repacks, you'll avoid the delta creation 99% of the time.

Ie somethng really simple like the appended.

		Linus
---

diff --git a/pack-objects.c b/pack-objects.c
index bed2497..cea63e7 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -988,6 +988,13 @@ static int try_delta(struct unpacked *tr
 		return -1;
 
 	/*
+	 * We do not bother to try a delta that we discarded
+	 * on an earlier try
+	 */
+	if (trg_entry->in_pack && trg_entry->in_pack == src_entry->in_pack)
+		return -1;
+
+	/*
 	 * If the current object is at pack edge, take the depth the
 	 * objects that depend on the current object into account --
 	 * otherwise they would become too deep.