Patchwork [8,of,8] util: implement zstd compression engine

login
register
mail settings
Submitter Gregory Szorc
Date Nov. 11, 2016, 9:23 a.m.
Message ID <c1b3f85fa82bd350d286.1478856220@ubuntu-vm-main>
Download mbox | patch
Permalink /patch/17475/
State Accepted
Headers show

Comments

Gregory Szorc - Nov. 11, 2016, 9:23 a.m.
# HG changeset patch
# User Gregory Szorc <gregory.szorc@gmail.com>
# Date 1478855407 28800
#      Fri Nov 11 01:10:07 2016 -0800
# Node ID c1b3f85fa82bd350d28669777022d02be9f72c3e
# Parent  2628b96b3884024e3c0552303d71bdd9fbd99a71
util: implement zstd compression engine

Now that zstd is vendored and being built (in some configurations), we
can implement a compression engine for zstd!

The zstd engine is a little different from existing engines. Because
it may not always be present, we have to defer load the module in case
importing it fails. We facilitate this via a cached property that holds
a reference to the module or None. The "available" method is
implemented to reflect reality.

The zstd engine declares its ability to handle bundles using the
"zstd" human name and the "ZS" internal name. The latter was chosen
because internal names are 2 characters (by only convention I think)
and "ZS" seems reasonable.

The engine, like others, supports specifying the compression level.
However, there are no consumers of this API that yet pass in that
argument. I have plans to change that, so stay tuned.

Since all we need to do to support bundle generation with a new
compression engine is implement and register the compression engine,
bundle generation with zstd "just works!" Tests demonstrating this
have been added.

How does performance of zstd for bundle generation compare? On the
mozilla-unified repo, `hg bundle --all -t <engine>-v2` yields the
following on my i7-6700K on Linux:

engine        CPU time     bundle size   vs orig size   throughput
none            97.0s     4,054,405,584     100.0%       41.8 MB/s
bzip2 (l=9)    393.6s       975,343,098      24.0%       10.3 MB/s
gzip (l=6)     184.0s     1,140,533,074      28.1%       22.0 MB/s
zstd (l=1)     108.2s     1,119,434,718      27.6%       37.5 MB/s
zstd (l=2)     111.3s     1,078,328,002      26.6%       36.4 MB/s
zstd (l=3)     113.7s     1,011,823,727      25.0%       35.7 MB/s
zstd (l=4)     116.0s     1,008,965,888      24.9%       35.0 MB/s
zstd (l=5)     121.0s       977,203,148      24.1%       33.5 MB/s
zstd (l=6)     131.7s       927,360,198      22.9%       30.8 MB/s
zstd (l=7)     139.0s       912,808,505      22.5%       29.2 MB/s
zstd (l=12)    198.1s       854,527,714      21.1%       20.5 MB/s
zstd (l=18)    681.6s       789,750,690      19.5%        5.9 MB/s

On compression, zstd for bundle generation delivers:

* better compression than gzip with significantly less CPU utilization
* better than bzip2 compression ratios while still being significantly
  faster than gzip
* ability to aggressively tune compression level to achieve
  significantly smaller bundles

That last point is important. With clone bundles, a server can
pre-generate a bundle file, upload it to a static file server, and
redirect clients to transparently download it during clone. The server
could choose to produce a zstd bundle with the highest compression
settings possible. This would take a very long time - a magnitude
longer than a typical zstd bundle generation - but the result would
be hundreds of megabytes smaller! For the clone volume we do at
Mozilla, this could translate to petabytes of bandwidth savings
per year and faster clones (due to smaller transfer size).

I don't have detailed numbers to report on decompression. However,
zstd decompression is fast: >1 GB/s output throughput on this machine,
even through the Python bindings. And it can do that regardless of the
compression level of the input. By the time you have enough data to
worry about overhead of decompression, you have plenty of other things
to worry about performance wise.

zstd is wins all around. I can't wait to implement support for it
on the wire protocol and in revlogs.
Bryan O'Sullivan - Nov. 11, 2016, 6:19 p.m.
On Fri, Nov 11, 2016 at 1:23 AM, Gregory Szorc <gregory.szorc@gmail.com>
wrote:

> zstd is wins all around. I can't wait to implement support for it
> on the wire protocol and in revlogs.
>

Very exciting!
via Mercurial-devel - Nov. 18, 2016, 12:13 a.m.
On Fri, Nov 11, 2016 at 10:19 AM, Bryan O'Sullivan <bos@serpentine.com> wrote:
>
> On Fri, Nov 11, 2016 at 1:23 AM, Gregory Szorc <gregory.szorc@gmail.com>
> wrote:
>>
>> zstd is wins all around. I can't wait to implement support for it
>> on the wire protocol and in revlogs.
>
>
> Very exciting!

Yep. Now queued. Thanks, Greg.

>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>

Patch

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -3105,5 +3105,50 @@  class _noopengine(compressionengine):
 
 compengines.register(_noopengine())
 
+class _zstdengine(compressionengine):
+    def name(self):
+        return 'zstd'
+
+    @propertycache
+    def _module(self):
+        # Not all installs have the zstd module available. So defer importing
+        # until first access.
+        try:
+            from . import zstd
+            # Force delayed import.
+            zstd.__version__
+            return zstd
+        except ImportError:
+            return None
+
+    def available(self):
+        return bool(self._module)
+
+    def bundletype(self):
+        return 'zstd', 'ZS'
+
+    def compressstream(self, it, opts=None):
+        opts = opts or {}
+        # zstd level 3 is almost always significantly faster than zlib
+        # while providing no worse compression. It strikes a good balance
+        # between speed and compression.
+        level = opts.get('level', 3)
+
+        zstd = self._module
+        z = zstd.ZstdCompressor(level=level).compressobj()
+        for chunk in it:
+            data = z.compress(chunk)
+            if data:
+                yield data
+
+        yield z.flush()
+
+    def decompressorreader(self, fh):
+        zstd = self._module
+        dctx = zstd.ZstdDecompressor()
+        return chunkbuffer(dctx.read_from(fh))
+
+compengines.register(_zstdengine())
+
 # convenient shortcut
 dst = debugstacktrace
diff --git a/tests/test-bundle-type.t b/tests/test-bundle-type.t
--- a/tests/test-bundle-type.t
+++ b/tests/test-bundle-type.t
@@ -35,17 +35,21 @@  bundle w/o type option
 
 test bundle types
 
-  $ for t in "None" "bzip2" "gzip" "none-v2" "v2" "v1" "gzip-v1"; do
-  >   echo % test bundle type $t
-  >   hg init t$t
+  $ testbundle() {
+  >   echo % test bundle type $1
+  >   hg init t$1
   >   cd t1
-  >   hg bundle -t $t ../b$t ../t$t
-  >   f -q -B6 -D ../b$t; echo
-  >   cd ../t$t
-  >   hg debugbundle ../b$t
-  >   hg debugbundle --spec ../b$t
+  >   hg bundle -t $1 ../b$1 ../t$1
+  >   f -q -B6 -D ../b$1; echo
+  >   cd ../t$1
+  >   hg debugbundle ../b$1
+  >   hg debugbundle --spec ../b$1
   >   echo
   >   cd ..
+  > }
+
+  $ for t in "None" "bzip2" "gzip" "none-v2" "v2" "v1" "gzip-v1"; do
+  >   testbundle $t
   > done
   % test bundle type None
   searching for changes
@@ -106,6 +110,38 @@  test bundle types
   c35a0f9217e65d1fdb90c936ffa7dbe679f83ddf
   gzip-v1
   
+#if zstd
+
+  $ for t in "zstd" "zstd-v2"; do
+  >   testbundle $t
+  > done
+  % test bundle type zstd
+  searching for changes
+  1 changesets found
+  HG20\x00\x00 (esc)
+  Stream params: sortdict([('Compression', 'ZS')])
+  changegroup -- "sortdict([('version', '02'), ('nbchanges', '1')])"
+      c35a0f9217e65d1fdb90c936ffa7dbe679f83ddf
+  zstd-v2
+  
+  % test bundle type zstd-v2
+  searching for changes
+  1 changesets found
+  HG20\x00\x00 (esc)
+  Stream params: sortdict([('Compression', 'ZS')])
+  changegroup -- "sortdict([('version', '02'), ('nbchanges', '1')])"
+      c35a0f9217e65d1fdb90c936ffa7dbe679f83ddf
+  zstd-v2
+  
+#else
+
+zstd is a valid engine but isn't available
+
+  $ hg -R t1 bundle -a -t zstd irrelevant.hg
+  abort: compression engine zstd could not be loaded
+  [255]
+
+#endif
 
 test garbage file