From: Nicolas Pitre <nico@cam.org>
To: Brian Downing <bdowning@lavos.net>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] apply delta depth bias to already deltified objects
Date: Thu, 12 Jul 2007 12:27:02 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0707121146550.32552@xanadu.home> (raw)
In-Reply-To: <20070712152016.GB19073@lavos.net>
On Thu, 12 Jul 2007, Brian Downing wrote:
> On Thu, Jul 12, 2007 at 02:38:30AM -0400, Nicolas Pitre wrote:
> > This apparently makes BRian's patological case worse (although better
> > than before his same-size-shallower patch), but I think that the
> > improvement in the general case is worth it. Even Brian's pack gets
> > smaller so...
>
> I've found why this makes my case worse, and I think it's correctable
> and will benefit everything when fixed:
>
> Let's say we've currently got a delta match of 11 bytes at depth 5.
> So trg_entry->delta_size = 11 and trg_entry->depth = 5. max_depth is
> 100.
>
> Now let's say the next object we're comparing against is at depth 2
> (src_entry->depth = 2). Even if we can find a delta of the same size
> we should take it.
>
> Now, with Nico's new patch:
>
> max_size = trg_entry->delta_size * max_depth /
> (max_depth - trg_entry->depth + 1);
>
> max_size is now 11. So far so good.
>
> Now, however, the other bias happens:
>
> max_size = max_size * (max_depth - src_entry->depth) / max_depth;
>
> max_size = 11 * (100 - 2) / 100;
> max_size = 1078 / 100;
> max_size = 10;
Hmmm... Integer truncation errors.
In theory, the allowed max_size should be slightly higher than what we
got in the depth 5 case because this case is less deep. So...
max_size = trg_entry->delta_size * max_depth /
(max_depth - trg_entry->depth + 1);
max_size = 11 * 100 / (100 - 5 + 1) = 11.4583
max_size = max_size * (max_depth - src_entry->depth) / max_depth;
max_size = 11.4583 * (100 - 2) / 100 = 11.2292
So the max_size, because the depth is less, is slightly higher.
> This was okay when max_size was always (trg_size/2 - 20) here, but now
> it's cutting it off too much. max_size is now 10, and we can't make
> a better depth match of the same size anymore.
>
> I think the second bias equation should be scaled so as not to take
> effect unless (src_entry->depth [+ 1?] > trg_entry->depth).
Better yet, the integer truncation error should be compensated for, with
this:
max_size =
(trg_entry->delta_size * max_depth + max_depth - trg_entry->depth) /
(max_depth - trg_entry->depth + 1);
Nicolas
next prev parent reply other threads:[~2007-07-12 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 6:38 [PATCH] apply delta depth bias to already deltified objects Nicolas Pitre
2007-07-12 15:20 ` Brian Downing
2007-07-12 16:27 ` Nicolas Pitre [this message]
2007-07-12 16:44 ` Brian Downing
2007-07-12 18:07 ` Nicolas Pitre
2007-07-12 18:33 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0707121146550.32552@xanadu.home \
--to=nico@cam.org \
--cc=bdowning@lavos.net \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).