Further adventures in revlog compression

[Bryan O'Sullivan]

On Wed, Jun 6, 2012 at 1:03 PM, Matt Mackall <mpm at selenic.com> wrote:

>
> Not sure why you didn't respond to my earlier suggestion:
>
> http://markmail.org/messageku54kxcs4obwso6<http://markmail.org/message/4ku54kxcs4obwso6>


Just too much mail to deal with, so some gets forgotten. I'll circle back
to that in a bit.


> I'm really not very interested in decreasing manifest compression. I've
> gotten numerous complaints that manifest disk space was already a
> serious problem (and indeed, it's been a determining factor for several
> projects in not using Mercurial).
>

Why isn't generaldelta turned on for the special case of the manifest,
then? That's presumably the source of the blowup in most cases.


> You're probably the first person to ever suggest trading manifest size
> for performance in this direction. If you didn't have the fairly unique
> situation of having a very large history that was also very linear,
> you'd probably be trying to go the other way.


That's not clear to me. The lz4 patch improves performance across the board
by trading off space. Both space and time changes are most visible with the
manifest, where perfrevlog performance improves by 2.5x and size increases
by 35%, but there's an effect on every other revlog, too.

The manifest is a bit of a distraction in this instance, in fact: it only
accounts for a small part of the improvement in e.g. update performance.
The rest is due to the effect of lz4 decompression on the reconstruction of
all the other revlogs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120606/f602e147/attachment.html>