[PATCH 4 of 4] revlog: separate methods for deltas and key frames compression/decompression

[Wojciech Lopata]

> But why can we not get the same gain from compressing both key frames and deltas the same?  Why would we ever want to apply some compression to a key frame, but not to a delta?

I probably misused 'compression' term.

I need to introduce additional step that would occur after new revision is added to a revlog, but before gziping the revision text.

This will let me to apply 'stem compression' (described in http://mercurial.selenic.com/wiki/ImprovingManifestCompressionPlan) to key frames only.

Implementing stem compression on the manifest level (before adding a revision to a revlog) actually bums manifest size, since it increases size of deltas in some cases (when new file is added or renamed).

I will not call it compression any more.

> -----Original Message-----
> From: Durham Goode
> Sent: Thursday, September 26, 2013 3:35 PM
> To: Wojciech Lopata; mercurial-devel at selenic.com
> Subject: Re: [PATCH 4 of 4] revlog: separate methods for deltas and key
> frames compression/decompression
> 
> On 9/26/13 3:32 PM, "Wojciech Lopata" <lopek at fb.com> wrote:
> 
> >> Do you have numbers showing what benefits an extension could get by
> >>doing key frame and delta compression differently?
> >
> >This vary. The biggest gain of being able to apply different
> >compressions for key frames and deltas I've seen for now was additional
> >5% manifest size reduction. I believe gain grows as repository grows,
> >but I haven't checked what the gain is on big repositories, since with
> >my draft, pure python implementation such conversion would take days.
> 
> 
> But why can we not get the same gain from compressing both key frames
> and deltas the same?  Why would we ever want to apply some compression
> to a key frame, but not to a delta?