Mercurial > hg
view mercurial/state.py @ 42043:1fac9b931d46
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 using the
mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite.
All tested repository use sparse-revlog and got all their delta recomputed.
The different compression level has a small effect on the repository size
(about 10% variation in the total range). My quick analysis is that revlog
mostly store small delta, that are not affected by the compression level much.
So the variation probably mostly comes from better compression of the snapshots
revisions, and snapshot revision only represent a small portion of the
repository content.
I also made some basic timings measurements. The "read" timings are gathered using
simple run of `hg perfrevlogrevisions`, the "write" timings using `hg
perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and
mozilla central). The timings are gathered on a generic machine, (not one of
our performance locked machine), so small variation might not be meaningful.
However large trend remains relevant.
Keep in mind that these numbers are not pure compression/decompression time.
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, the higher compression levels improve "write" performance
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
author | Pierre-Yves David <pierre-yves.david@octobus.net> |
---|---|
date | Wed, 27 Mar 2019 18:35:27 +0100 |
parents | 050ea8eb42a5 |
children | 5f2f6912c9e6 |
line wrap: on
line source
# state.py - writing and reading state files in Mercurial # # Copyright 2018 Pulkit Goyal <pulkitmgoyal@gmail.com> # # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. """ This file contains class to wrap the state for commands and other related logic. All the data related to the command state is stored as dictionary in the object. The class has methods using which the data can be stored to disk in a file under .hg/ directory. We store the data on disk in cbor, for which we use the CBOR format to encode the data. """ from __future__ import absolute_import from . import ( error, util, ) from .utils import ( cborutil, ) class cmdstate(object): """a wrapper class to store the state of commands like `rebase`, `graft`, `histedit`, `shelve` etc. Extensions can also use this to write state files. All the data for the state is stored in the form of key-value pairs in a dictionary. The class object can write all the data to a file in .hg/ directory and can populate the object data reading that file. Uses cbor to serialize and deserialize data while writing and reading from disk. """ def __init__(self, repo, fname): """ repo is the repo object fname is the file name in which data should be stored in .hg directory """ self._repo = repo self.fname = fname def read(self): """read the existing state file and return a dict of data stored""" return self._read() def save(self, version, data): """write all the state data stored to .hg/<filename> file we use third-party library cbor to serialize data to write in the file. """ if not isinstance(version, int): raise error.ProgrammingError("version of state file should be" " an integer") with self._repo.vfs(self.fname, 'wb', atomictemp=True) as fp: fp.write('%d\n' % version) for chunk in cborutil.streamencode(data): fp.write(chunk) def _read(self): """reads the state file and returns a dictionary which contain data in the same format as it was before storing""" with self._repo.vfs(self.fname, 'rb') as fp: try: int(fp.readline()) except ValueError: raise error.CorruptedState("unknown version of state file" " found") return cborutil.decodeall(fp.read())[0] def delete(self): """drop the state file if exists""" util.unlinkpath(self._repo.vfs.join(self.fname), ignoremissing=True) def exists(self): """check whether the state file exists or not""" return self._repo.vfs.exists(self.fname)