Re: 1.3.0 creating bigger packs than 1.2.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <junkio@xxxxxxx> wrote:
> Nicolas Pitre <nico@xxxxxxx> writes:
> 
> >> But I suspect we have a built-in "we sort bigger to smaller, and
> >> we cut off when we switch bins" somewhere in find_delta() loop,
> >> which I do not recall touching when I did that change, so that
> >> may be interfering and preventing 0-11-AdjLite.deg from all over
> >> the place to delta against each other.
> >
> > I just cannot find something that would do that in the code.  When 
> > --no-reuse-delta is specified, the only things that will break the loop
> > in find_delta() is when try_delta() returns -1, and that happens only 
> > when changing object type or when the size difference is too big, but 
> > nothing looks at the name hash.
> 
> The list is sorted by type then hash then size (type_size_sort),
> so if you have t/Makefile that are big medium small too-small
> and then doc/Makefile that are big medium, once you see the
> too-small t/Makefile it would not consider the big doc/Makefile
> as a candidate X-<.
> 
> This _might_ improve things:
> 
> diff --git a/pack-objects.c b/pack-objects.c
> index 09f4f2c..0c6abe9 100644
> --- a/pack-objects.c
> +++ b/pack-objects.c
> @@ -1037,7 +1039,7 @@ static int try_delta(struct unpacked *cu
>  	sizediff = oldsize > size ? oldsize - size : size - oldsize;
>  
>  	if (size < 50)
> -		return -1;
> +		return 0;
>  	if (old_entry->depth >= max_depth)
>  		return 0;
>  
> @@ -1052,7 +1054,7 @@ static int try_delta(struct unpacked *cu
>  	if (cur_entry->delta)
>  		max_size = cur_entry->delta_size-1;
>  	if (sizediff >= max_size)
> -		return -1;
> +		return 0;
>  	delta_buf = diff_delta(old->data, oldsize,
>  			       cur->data, size, &delta_size, max_size);
>  	if (!delta_buf)

Holy cow, it did:

  Total 46391, written 46391 (delta 8391), reused 37774 (delta 0)
   46M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack

That's the smallest packing I've seen yet.  And it doesn't have a
negative affect on repacking GIT either.

-- 
Shawn.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]