[PATCH 3 of 8 "] compression: introduce a `storage.revlog.zlib.level` configuration

Gregory Szorc gregory.szorc at gmail.com
Tue Apr 2 14:16:32 EDT 2019


On Tue, Apr 2, 2019 at 12:29 AM Josef 'Jeff' Sipek <jeffpc at josefsipek.net>
wrote:

> On Sun, Mar 31, 2019 at 17:36:19 +0200, Pierre-Yves David wrote:
> ...
> > compression: introduce a `storage.revlog.zlib.level` configuration
> >
> > This option control the zlib compression level used when compression
> revlog
> > chunk.
> >
> > This is also a good excuse to pave the way for a similar configuration
> option
> > for the zstd compression engine. Having a dedicated option for each
> compression
> > algorithm is useful because they don't support the same range of values.
> >
> > Using a higher zlib compression impact CPU consumption at compression
> time, but
> > does not directly affected decompression time. However dealing with small
> > compressed chunk can directly help decompression and indirectly help
> other
> > revlog logic.
> >
> > I ran some basic test on repositories using different level. I am user
> the
>
> s/user/using/ ?
>
> ...
> > I also made some basic timing measurement. The "read" timing are
> gathered using
> > simple run of `hg perfrevlogrevisions`, the "write" measurement using `hg
> > perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and
> > mozilla central). The timing are gathered on a generic machine, (not
> one  of
> > our performance locked machine), so small variation might not be
> meaningful.
>
> You did more than one measurement, so measurement -> measurements, and
> timing -> timings?  Alternatively, keep the singular but then make the
> verbs
> match: are -> is.
>
> Sorry to nit-pick, but since this text will end up in the commit
> messages...
> :)
>
> > However large trend remains relevant.
> >
> > Keep in mind that these number are not pure compression/decompression
> time.
>
> s/number/numbers/
>
> > They also involve the full revlog logic. In particular the difference in
> chunk
> > size has an impact on the delta chain structure, affecting performance
> when
> > writing or reading them.
> >
> > On read/write performance, the compression level has a bigger impact.
> > Counter-intuitively, higher compression level raise better "write"
> performance
>
> s/raise better/increase/ ?
>
> This actually confuses me a bit.  Based on the table below, it looks like
> higher compression level has non-linear effect on read/write performance.
> Maybe I'm not understanding what you meant by 'raise "better"'.
>
> While I expect to see a "hump" in *write* performance (because high zlib
> compression levels are such cpu hogs), I didn't expect to see one for
> *read*
> perfomance.  I suppose the read hump could be explained by the shape of the
> DAG, as you point out.
>

https://gregoryszorc.com/blog/2017/03/07/better-compression-with-zstandard/
has some nice charts graphing (de)compression speed versus compression
levels for various compression formats. zlib and zstd decompression speed
should be relatively linear on the decompression side. Exception is
negative compression levels with zstd, which will be faster than positive
levels.

When Python comes into play, the read speed can be influenced by a number
of factors, including the overhead of allocating the output buffer.
Measuring performance of thousands of small operations quickly turns into
measuring the efficiency/overhead of the Python bindings to the compression
library and Python itself. One of the things we do with zstd revlogs is
reuse the decompression context (self._dctx), whereas zlib revlogs call
zlib.decompress() on every item. There is undoubtedly some overhead to
constructing those objects and constructing decompressors to support large
window sizes (read: higher compression levels) may introduce additional
overhead. I dunno.

FWIW the `hg perfrevlogchunks` command isolates the various "stages" of
reading from revlogs and can be very useful for isolating the compression
performance. It even has separate benchmarks for measuring zlib versus zstd
compression!


>
> > for the large repositories in our tested setting. Maybe because the last
> 5000
> > delta chain end up having a very different shape in this specific spot?
> Or maybe
> > because of a more general trend of better delta chains thanks to the
> smaller
> > chunk and snapshot.
> >
> > This series does not intend to change the default compression level.
> However,
> > these result call for a deeper analysis of this performance difference
> in the
> > future.
> >
> > Full data
> > =========
> >
> > repo   level  .hg/store size  00manifest.d read       write
> > ----------------------------------------------------------------
> > mercurial  1      49,402,813     5,963,475   0.170159  53.250304
> > mercurial  6      47,197,397     5,875,730   0.182820  56.264320
> > mercurial  9      47,121,596     5,849,781   0.189219  56.293612
> >
> > pypy       1     370,830,572    28,462,425   2.679217 460.721984
> > pypy       6     340,112,317    27,648,747   2.768691 467.537158
> > pypy       9     338,360,736    27,639,003   2.763495 476.589918
> >
> > netbeans   1   1,281,847,810   165,495,457 122.477027 520.560316
> > netbeans   6   1,205,284,353   159,161,207 139.876147 715.930400
> > netbeans   9   1,197,135,671   155,034,586 141.620281 678.297064
> >
> > mozilla    1   2,775,497,186   298,527,987 147.867662 751.263721
> > mozilla    6   2,596,856,420   286,597,671 170.572118 987.056093
> > mozilla    9   2,587,542,494   287,018,264 163.622338 739.803002
> ...
> > diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
> > --- a/mercurial/help/config.txt
> > +++ b/mercurial/help/config.txt
> > @@ -1881,6 +1881,11 @@ category impact performance and reposito
> >      This option is enabled by default. When disabled, it also disables
> the
> >      related ``storage.revlog.reuse-external-delta-parent`` option.
> >
> > +``revlog.zlib.level``
> > +    Zlib compression level used when storing data into the repository.
> Accepted
> > +    Value range from 1 (lowest compression) to 9 (highest compression).
> Zlib
> > +    default value is 6.
>
> I know this is very unlikely to change, but does it make sense to say what
> an external libarary's defaults are?
>
>
> Thanks for doing this! :)
>
> Jeff.
>
> --
> Reality is merely an illusion, albeit a very persistent one.
>                 - Albert Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190402/38844f9e/attachment.html>


More information about the Mercurial-devel mailing list