mercurial-scm/hg: mercurial/revlog.py comparison

comparison mercurial/revlog.py @ 30817:2b279126b8f5

revlog: use compression engine APIs for decompression Now that compression engines declare their header in revlog chunks and can decompress revlog chunks, we refactor revlog.decompress() to use them. Making full use of the property that revlog compressor objects are reusable, revlog instances now maintain a dict mapping an engine's revlog header to a compressor object. This is not only a performance optimization for engines where compressor object reuse can result in better performance, but it also serves as a cache of header values so we don't need to perform redundant lookups against the compression engine manager. (Yes, I measured and the overhead of a function call versus a dict lookup was observed.) Replacing the previous inline lookup table with a dict lookup was measured to make chunk reading ~2.5% slower on changelogs and ~4.5% slower on manifests. So, the inline lookup table has been mostly preserved so we don't lose performance. This is unfortunate. But many decompression operations complete in microseconds, so Python attribute lookup, dict lookup, and function calls do matter. The impact of this change on mozilla-unified is as follows: $ hg perfrevlogchunks -c ! chunk ! wall 1.953663 comb 1.950000 user 1.920000 sys 0.030000 (best of 6) ! wall 1.946000 comb 1.940000 user 1.910000 sys 0.030000 (best of 6) ! chunk batch ! wall 1.791075 comb 1.800000 user 1.760000 sys 0.040000 (best of 6) ! wall 1.785690 comb 1.770000 user 1.750000 sys 0.020000 (best of 6) $ hg perfrevlogchunks -m ! chunk ! wall 2.587262 comb 2.580000 user 2.550000 sys 0.030000 (best of 4) ! wall 2.616330 comb 2.610000 user 2.560000 sys 0.050000 (best of 4) ! chunk batch ! wall 2.427092 comb 2.420000 user 2.400000 sys 0.020000 (best of 5) ! wall 2.462061 comb 2.460000 user 2.400000 sys 0.060000 (best of 4) Changelog chunk reading is slightly faster but manifest reading is slower. What gives? On this repo, 99.85% of changelog entries are zlib compressed (the 'x' header). On the manifest, 67.5% are zlib and 32.4% are '\0'. This patch swapped the test order of 'x' and '\0' so now 'x' is tested first. This makes changelogs faster since they almost always hit the first branch. This makes a significant percentage of manifest '\0' chunks slower because that code path now performs an extra test. Yes, I too can't believe we're able to measure the impact of an if..elif with simple string compares. I reckon this code would benefit from being written in C...

author	Gregory Szorc <gregory.szorc@gmail.com>
date	Fri, 13 Jan 2017 19:58:00 -0800
parents	78ac56aebab6
children	4c0a5a256ae8

comparison

equal deleted inserted replaced

-:96f811bceb85
+:2b279126b8f5
 util,
 )
 _pack = struct.pack
 _unpack = struct.unpack
-_decompress = zlib.decompress
+# Aliased for performance.
+_zlibdecompress = zlib.decompress
 # revlog header flags
 REVLOGV0 = 0
 REVLOGNG = 1
 REVLOGNGINLINEDATA = (1 << 16)
 self.nodemap = self._nodecache = nodemap
 if not self._chunkcache:
 self._chunkclear()
 # revnum -> (chain-length, sum-delta-length)
 self._chaininfocache = {}
+# revlog header -> revlog compressor
+self._decompressors = {}
 @util.propertycache
 def _compressor(self):
 return util.compengines['zlib'].revlogcompressor()
 The chunk is expected to begin with a header identifying the
 format type so it can be routed to an appropriate decompressor.
 """
 if not data:
 return data
+# Revlogs are read much more frequently than they are written and many
+# chunks only take microseconds to decompress, so performance is
+# important here.
+#
+# We can make a few assumptions about revlogs:
+#
+# 1) the majority of chunks will be compressed (as opposed to inline
+#    raw data).
+# 2) decompressing *any* data will likely by at least 10x slower than
+#    returning raw inline data.
+# 3) we want to prioritize common and officially supported compression
+#    engines
+#
+# It follows that we want to optimize for "decompress compressed data
+# when encoded with common and officially supported compression engines"
+# case over "raw data" and "data encoded by less common or non-official
+# compression engines." That is why we have the inline lookup first
+# followed by the compengines lookup.
+#
+# According to `hg perfrevlogchunks`, this is ~0.5% faster for zlib
+# compressed chunks. And this matters for changelog and manifest reads.
 t = data[0]
-if t == '\0':
-return data
 if t == 'x':
 try:
-return _decompress(data)
+return _zlibdecompress(data)
 except zlib.error as e:
 raise RevlogError(_('revlog decompress error: %s') % str(e))
-if t == 'u':
+# '\0' is more common than 'u' so it goes first.
+elif t == '\0':
+return data
+elif t == 'u':
 return util.buffer(data, 1)
-raise RevlogError(_('unknown compression type %r') % t)
+try:
+compressor = self._decompressors[t]
+except KeyError:
+try:
+engine = util.compengines.forrevlogheader(t)
+compressor = engine.revlogcompressor()
+self._decompressors[t] = compressor
+except KeyError:
+raise RevlogError(_('unknown compression type %r') % t)
+return compressor.decompress(data)
 def _isgooddelta(self, d, textlen):
 """Returns True if the given delta is good. Good means that it is within
 the disk span, disk size, and chain length bounds that we know to be
 performant."""

Mercurial > public > mercurial-scm > hg

comparison mercurial/revlog.py @ 30817:2b279126b8f5