# HG changeset patch # User Gregory Szorc # Date 2016-08-15 04:29:46 # Node ID 58467204cac010b3cda3fbe9d5fd0785760ba265 # Parent 28591876fa638c01abd28857e9bcbe69d54819fb hgweb: tweak zlib chunking behavior When doing streaming compression with zlib, zlib appears to emit chunks with data after ~20-30kb on average is available. In other words, most calls to compress() return an empty string. On the mozilla-unified repo, only 48,433 of 921,167 (5.26%) of calls to compress() returned data. In other words, we were sending hundreds of thousands of empty chunks via a generator where they touched who knows how many frames (my guess is millions). Filtering out the empty chunks from the generator cuts down on overhead. In addition, we were previously feeding 8kb chunks into zlib compression. Since this function tends to emit *compressed* data after 20-30kb is available, it would take several calls before data was produced. We increase the amount of data fed in at a time to 32kb. This reduces the number of calls to compress() from 921,167 to 115,146. It also reduces the number of output chunks from 48,433 to 31,377. This does increase the average output chunk size by a little. But I don't think this will matter in most scenarios. The combination of these 2 changes appears to shave ~6s CPU time or ~3% from a server serving the mozilla-unified repo. diff --git a/mercurial/hgweb/protocol.py b/mercurial/hgweb/protocol.py --- a/mercurial/hgweb/protocol.py +++ b/mercurial/hgweb/protocol.py @@ -79,10 +79,14 @@ class webproto(wireproto.abstractserverp # the server's network or CPU. z = zlib.compressobj(self.ui.configint('server', 'zliblevel', -1)) while True: - chunk = cg.read(4096) + chunk = cg.read(32768) if not chunk: break - yield z.compress(chunk) + data = z.compress(chunk) + # Not all calls to compress() emit data. It is cheaper to inspect + # that here than to send it via the generator. + if data: + yield data yield z.flush() def _client(self): return 'remote:%s:%s:%s' % (