threads / patch / 3429

patchrelax delta selection filtering in pack-objects

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

## tl;dr

4 messages between Feb 22, 2006 and Feb 22, 2006. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Nicolas Pitre· Feb 22, 2006, 01:39 UTC · lore

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
Show changes to pack-objects.c +2 −3
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
Junio C Hamano· Feb 22, 2006, 07:23 UTC · re: Junio C Hamano · lore

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

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.

Nicolas Pitre· Feb 22, 2006, 16:04 UTC · re: Junio C Hamano · lore

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

On Tue, 21 Feb 2006, Junio C Hamano wrote:
Show 10 quoted lines
> 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

← back to recent threads