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

Durham Goode durham at fb.com
Fri Sep 27 01:48:12 UTC 2013


On 9/26/13 3:48 PM, "Wojciech Lopata" <lopek at fb.com> wrote:

>> 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.

>From talking to Wojciech in person, there are certain compression
algorithms that can be applied to key frames but not to deltas, and if
they were applied to the actual manifest (prior to deltafication) can
result in larger deltas overall.  So splitting these functions up allows
us to compress key frames on their own.  Stem compressions (as described
in the Manifest compression wiki page) is an example of this.

I would still like to see what the actual benefits are (i.e. numbers) are
before adding the extra complexity to revlog.




More information about the Mercurial-devel mailing list