[PATCH] relax delta selection filtering in pack-objects

[PATCH] relax delta selection filtering in pack-objects

[Nicolas Pitre]

This change provides a 8% saving on the pack size with a 4% CPU time 
increase for git-repack -a on the current git archive.

Signed-off-by: Nicolas Pitre <nico@cam.org>

---

 pack-objects.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

2aed7126f9b44d9ef953e8a1cbeab34356410842
diff --git a/pack-objects.c b/pack-objects.c
index ceb107f..4f8814d 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -748,11 +748,10 @@ static int try_delta(struct unpacked *cu
 	}
 
 	size = cur_entry->size;
-	if (size < 50)
-		return -1;
 	oldsize = old_entry->size;
 	sizediff = oldsize > size ? oldsize - size : size - oldsize;
-	if (sizediff > size / 8)
+
+	if (size < 50)
 		return -1;
 	if (old_entry->depth >= max_depth)
 		return 0;
-- 
1.2.2.g6643-dirty

Re: [PATCH] relax delta selection filtering in pack-objects

[Junio C Hamano]

I haven't dug into the issue yet, but these four delta series
seem to break the testsuite.

Re: [PATCH] relax delta selection filtering in pack-objects

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> I haven't dug into the issue yet, but these four delta series
> seem to break the testsuite.

I bisected.  It is the adler32 one -- since it makes the
generated delta much smaller, it is understandable that it would
interact with the break/rename heuristics.  It is not strictly
breakage in that sense -- we just need to readjust the
heuristics thresholds for those algorithms.

Re: [PATCH] relax delta selection filtering in pack-objects

[Nicolas Pitre]

On Tue, 21 Feb 2006, Junio C Hamano wrote:

> Junio C Hamano <junkio@cox.net> writes:
> 
> > I haven't dug into the issue yet, but these four delta series
> > seem to break the testsuite.
> 
> I bisected.  It is the adler32 one -- since it makes the
> generated delta much smaller, it is understandable that it would
> interact with the break/rename heuristics.  It is not strictly
> breakage in that sense -- we just need to readjust the
> heuristics thresholds for those algorithms.

I had a quick look and that code rather looks like black magic to me atm.
I however found a memory leak in diffcore-rename.c:estimate_similarity():

        delta = diff_delta(src->data, src->size,
                           dst->data, dst->size,
                           &delta_size, delta_limit);
        if (!delta)
                /* If delta_limit is exceeded, we have too much differences */
                return 0;

        /* A delta that has a lot of literal additions would have
         * big delta_size no matter what else it does.
         */
        if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
                return 0;
                   \________ delta memory is leaked.


Nicolas