Re: 1.3.0 creating bigger packs than 1.2.3

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> 
> > I just spent some time bisecting this issue and it looks like the
> > following change by Junio may be the culprit:
> >
> >   commit 1d6b38cc76c348e2477506ca9759fc241e3d0d46
[snip]
> Unfortunately, that is not the same hash we use in v1.3.0, so we
> need to look elsewhere for interactions.

Pity.  Then either bisect goofed or there was a goof in meatspace
while using bisect.  I honestly expected bisect to point at the
problem commit.  I tried reverting 1d6b38cc but it didn't apply
cleanly and I didn't feel like working through all of the conflicts
at the time.
 
[snip]
> The earlier observation by Linus on reverting eeef7135 is
> consistent with it; that commit was the one that introduced
> v1.3.0 hash.

Yet reverting that didn't help either.
 
[snip]
> You could try this patch to resurrect the hash used in v1.2.3,
> and you may get better packing for your particular repository;
> but I am not sure if it gives better results in the general
> case.  I am running the test myself now while waiting for my
> day-job database to load X-<.
[snip]

Nope.  When applied to 'next' it didn't help very much:

  Total 46391, written 46391 (delta 6466), reused 38662 (delta 0)
  118M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack


Just to note: the 1.3.0 packer is saving 1M in the GIT repository
over the 1.2.3 packer.  So for a real project it does seem to have
some benefit.  And if you benchmarked the 1.3.0 packer against
the Linux kernel and found it to be better than the 1.2.3 packer
that's even better.

I think this repository of mine may just be a degenerate case which
GIT doesn't pack very well.  GIT can't be all things to all people!

-- 
Shawn.