<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 27, 2016 at 6:45 AM, Pierre-Yves David <span dir="ltr"><<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank">pierre-yves.david@ens-lyon.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 09/25/2016 10:42 PM, Gregory Szorc wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
# HG changeset patch<br>
# User Gregory Szorc <<a href="mailto:gregory.szorc@gmail.com" target="_blank">gregory.szorc@gmail.com</a>><br>
# Date 1474830761 25200<br>
# Sun Sep 25 12:12:41 2016 -0700<br>
# Node ID f6bb4ff0a8c47b099157e615a2874c<wbr>193ac77512<br>
# Parent 2dc93677a8836d2365b561d1ba79f6<wbr>2ff68a4f23<br>
exchange: refactor APIs to obtain bundle data (API)<br>
<br>
Currently, exchange.getbundle() returns either a cg1unpacker or a<br>
util.chunkbuffer (in the case of bundle2). This is kinda OK, as<br>
both expose a .read() to consumers. However, localpeer.getbundle()<br>
has code inferring what the response type is based on arguments and<br>
converts the util.chunkbuffer returned in the bundle2 case to a<br>
bundle2.unbundle20 instance. This is a sign that the API for<br>
exchange.getbundle() is not ideal because it doesn't consistently<br>
return an "unbundler" instance.<br>
</blockquote>
<br></span>
I wonder how much this is used in extension. Should we keep the old API with a deprecation warning for a version ?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In addition, unbundlers mask the fact that there is an underlying<br>
generator of changegroup data. In both cg1 and bundle2, this generator<br>
is being fed into a util.chunkbuffer so it can be re-exposed as a<br>
file object.<br>
<br>
util.chunkbuffer is a nice abstraction. However, it should only be<br>
used "at the edges." This is because keeping data as a generator is<br>
more efficient than converting it to a chunkbuffer, especially if we<br>
convert that chunkbuffer back to a generator (as is the case in some<br>
code paths currently).<br>
</blockquote>
<br></span>
I know that the chunkbuffer+groupchunk is not removed yet. But can you remind up of the expected performance gain when the refactoring is done doing?<span class=""><br></span></blockquote><div><br></div>I think we could see a 5-10% CPU reduction on the server when everything is done.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch splits exchange.getbundle() into 2 functions. 1 returns<br>
an iterator over raw chunks (along with a flag saying whether it is<br>
bundle2). The other returns an "unbundler" instance.<br>
</blockquote>
<br></span>
Given how few call site we have, I wonder if we really need 2 functions. Could we simply move to getbundlechunks? And have the unbundler logic in the one place where we needs it.<br>
<br>
There seems to already be "I'm requesting" a bundle2 logic here so inlining this would be fine. We need to perform such logic in the client in all case because of the remote (ssh/http) anyway.<br>
<br>
This would allow us to remove the 'isbundle2' flag from getbundlechunks too. That flags seems a bit awkward to me.<span class=""><br></span></blockquote><div><br></div><div>The APIs around cg1 vs bundle2 are wonky and often require the client to know what is requesting before the fact. In the ideal world callers would pass "bundlecaps" or some such and get a generic type/interface back. There is a lot of follow-up improvement that could be made. I didn't want to scope bloat to fix all the APIs. I think this refactor is a strict improvement because it provides a facility for accessing the low-level generator, which we can now use in performance sensitive applications.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Callers of exchange.getbundle() have been updated to use the<br>
appropriate new API.<br>
<br>
There is a minor change of behavior in test-getbundle.t. This is<br>
because `hg debuggetbundle` isn't defining bundlecaps. As a result,<br>
a cg1 data stream and unpacker is being produced. This is getting fed<br>
into a new bundle20 instance via bundle2.writebundle(), which uses<br>
a backchannel mechanism between changegroup generation to add the<br>
"nbchanges" part parameter. I never liked this backchannel mechanism<br>
and I plan to remove it someday. `hg bundle` still produces the<br>
"nbchanges" part parameter, so there should be no user-visible<br>
change of behavior. I consider this "regression" a bug in<br>
`hg debuggetbundle`. And that bug is captured by an existing<br>
"TODO" in the code to use bundle2 capabilities.<br>
</blockquote>
<br></span>
How hard would it be to fix this 'debuggetbundle' thingy beforehand?<br></blockquote><div><br></div><div>debuggetbundle is already incomplete. I didn't want to scope bloat this work to fix an existing, unrelated deficiency. I'm not sure how much work fixing debuggetbundle would be.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
diff --git a/mercurial/exchange.py b/mercurial/exchange.py<br>
--- a/mercurial/exchange.py<br>
+++ b/mercurial/exchange.py<br>
@@ -1526,43 +1526,38 @@ def getbundle2partsgenerator(stepn<wbr>ame, i<br>
return func<br>
return dec<br>
<br>
def bundle2requested(bundlecaps):<br>
if bundlecaps is not None:<br>
return any(cap.startswith('HG2') for cap in bundlecaps)<br>
return False<br>
<br>
-def getbundle(repo, source, heads=None, common=None, bundlecaps=None,<br>
- **kwargs):<br>
- """return a full bundle (with potentially multiple kind of parts)<br>
+def getbundlechunks(repo, source, heads=None, common=None, bundlecaps=None,<br>
+ **kwargs):<br>
+ """Return chunks constituting a bundle's raw data.<br>
<br>
Could be a bundle HG10 or a bundle HG20 depending on bundlecaps<br>
- passed. For now, the bundle can contain only changegroup, but this will<br>
- changes when more part type will be available for bundle2.<br>
+ passed.<br>
<br>
- This is different from changegroup.getchangegroup that only returns an HG10<br>
- changegroup bundle. They may eventually get reunited in the future when we<br>
- have a clearer idea of the API we what to query different data.<br>
-<br>
- The implementation is at a very early stage and will get massive rework<br>
- when the API of bundle is refined.<br>
+ Returns a 2-tuple of (isbundle2, chunks) with the 2nd item being an<br>
+ iterator over raw chunks (of varying sizes).<br>
"""<br>
usebundle2 = bundle2requested(bundlecaps)<br>
# bundle10 case<br>
if not usebundle2:<br>
if bundlecaps and not kwargs.get('cg', True):<br>
raise ValueError(_('request for bundle10 must include changegroup'))<br>
<br>
if kwargs:<br>
raise ValueError(_('unsupported getbundle arguments: %s')<br>
% ', '.join(sorted(kwargs.keys())))<br>
outgoing = _computeoutgoing(repo, heads, common)<br>
- return changegroup.getchangegroup(rep<wbr>o, source, outgoing,<br>
- bundlecaps=bundlecaps)<br>
+ bundler = changegroup.getbundler('01', repo, bundlecaps)<br>
+ return False, changegroup.getsubsetraw(repo, outgoing, bundler, source)<br>
<br>
# bundle20 case<br>
b2caps = {}<br>
for bcaps in bundlecaps:<br>
if bcaps.startswith('bundle2='):<br>
blob = urlreq.unquote(bcaps[len('bund<wbr>le2='):])<br>
b2caps.update(bundle2.decodec<wbr>aps(blob))<br>
bundler = bundle2.bundle20(repo.ui, b2caps)<br>
@@ -1570,17 +1565,32 @@ def getbundle(repo, source, heads=None,<br>
kwargs['heads'] = heads<br>
kwargs['common'] = common<br>
<br>
for name in getbundle2partsorder:<br>
func = getbundle2partsmapping[name]<br>
func(bundler, repo, source, bundlecaps=bundlecaps, b2caps=b2caps,<br>
**kwargs)<br>
<br>
- return util.chunkbuffer(bundler.getch<wbr>unks())<br>
+ return usebundle2, bundler.getchunks()<br>
+<br>
+def getunbundler(repo, *args, **kwargs):<br>
+ """Obtain an unbundler from arguments.<br>
+<br>
+ This is essentially a wrapper around ``getbundlechunks()`` that converts<br>
+ the result to an unbundler instance.<br>
+<br>
+ Where performance is critical, ``getbundlechunks()`` should be used.<br>
+ """<br>
+ isbundle2, chunks = getbundlechunks(repo, *args, **kwargs)<br>
+<br>
+ if isbundle2:<br>
+ return bundle2.getunbundler(repo.ui, util.chunkbuffer(chunks))<br>
+ else:<br>
+ return changegroup.getunbundler('01', util.chunkbuffer(chunks), None)<br>
<br>
@getbundle2partsgenerator('ch<wbr>angegroup')<br>
def _getbundlechangegrouppart(bund<wbr>ler, repo, source, bundlecaps=None,<br>
b2caps=None, heads=None, common=None, **kwargs):<br>
"""add a changegroup part to the requested bundle"""<br>
cg = None<br>
if kwargs.get('cg', True):<br>
# build changegroup bundle here.<br>
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py<br>
--- a/mercurial/localrepo.py<br>
+++ b/mercurial/localrepo.py<br>
@@ -144,24 +144,19 @@ class localpeer(peer.peerrepository)<wbr>:<br>
def heads(self):<br>
return self._repo.heads()<br>
<br>
def known(self, nodes):<br>
return self._repo.known(nodes)<br>
<br>
def getbundle(self, source, heads=None, common=None, bundlecaps=None,<br>
**kwargs):<br>
- cg = exchange.getbundle(self._repo, source, heads=heads,<br>
- common=common, bundlecaps=bundlecaps, **kwargs)<br>
- if bundlecaps is not None and 'HG20' in bundlecaps:<br>
- # When requesting a bundle2, getbundle returns a stream to make the<br>
- # wire level function happier. We need to build a proper object<br>
- # from it in local peer.<br>
- cg = bundle2.getunbundler(self.ui, cg)<br>
- return cg<br>
+ return exchange.getunbundler(self._re<wbr>po, source, heads=heads,<br>
+ common=common, bundlecaps=bundlecaps,<br>
+ **kwargs)<br>
<br>
# TODO We might want to move the next two calls into legacypeer and add<br>
# unbundle instead.<br>
<br>
def unbundle(self, cg, heads, url):<br>
"""apply a bundle on a repo<br>
<br>
This function handles the repo locking itself."""<br>
diff --git a/mercurial/wireproto.py b/mercurial/wireproto.py<br>
--- a/mercurial/wireproto.py<br>
+++ b/mercurial/wireproto.py<br>
@@ -767,18 +767,20 @@ def getbundle(repo, proto, others):<br>
elif keytype != 'plain':<br>
raise KeyError('unknown getbundle option type %s'<br>
% keytype)<br>
<br>
if not bundle1allowed(repo, 'pull'):<br>
if not exchange.bundle2requested(opts<wbr>.get('bundlecaps')):<br>
return ooberror(bundle2required)<br>
<br>
- cg = exchange.getbundle(repo, 'serve', **opts)<br>
- return streamres(proto.groupchunks(cg<wbr>))<br>
+ isbundle2, chunks = exchange.getbundlechunks(repo, 'serve', **opts)<br>
+ # TODO avoid util.chunkbuffer() here since it is adding overhead to<br>
+ # what is fundamentally a generator proxying operation.<br>
+ return streamres(proto.groupchunks(ut<wbr>il.chunkbuffer(chunks)))<br>
<br>
@wireprotocommand('heads')<br>
def heads(repo, proto):<br>
h = repo.heads()<br>
return encodelist(h) + "\n"<br>
<br>
@wireprotocommand('hello')<br>
def hello(repo, proto):<br>
diff --git a/tests/test-getbundle.t b/tests/test-getbundle.t<br>
--- a/tests/test-getbundle.t<br>
+++ b/tests/test-getbundle.t<br>
@@ -165,17 +165,17 @@ Get branch and merge:<br>
<wbr>8365676dbab05860ce0d9110f2af51<wbr>368b961bbd<br>
<wbr>0b2f73f04880d9cb6a5cd8a757f0db<wbr>0ad01e32c3<br>
<br>
= Test bundle2 =<br>
<br>
$ hg debuggetbundle repo bundle -t bundle2<br>
$ hg debugbundle bundle<br>
Stream params: {}<br>
- changegroup -- "sortdict([('version', '01'), ('nbchanges', '18')])"<br>
+ changegroup -- "sortdict([('version', '01')])"<br>
<wbr>7704483d56b2a7b5db54dcee7c6237<wbr>8ac629b348<br>
<wbr>29a4d1f17bd3f0779ca0525bebb1cf<wbr>b51067c738<br>
<wbr>713346a995c363120712aed1aee7e0<wbr>4afd867638<br>
<wbr>d5f6e1ea452285324836a49d7d3c2a<wbr>63cfed1d31<br>
<wbr>ff42371d57168345fdf1a3aac66a51<wbr>f6a45d41d2<br>
<wbr>bac16991d12ff45f9dc43c52da1946<wbr>dfadb83e80<br>
<wbr>6621d79f61b23ec74cf4b69464343d<wbr>9e0980ec8b<br>
<wbr>8931463777131cd73923e560b76006<wbr>1f2aa8a4bc<br></div></div>
______________________________<wbr>_________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@mercurial-scm.org" target="_blank">Mercurial-devel@mercurial-scm.<wbr>org</a><br>
<a href="https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/<wbr>mailman/listinfo/mercurial-dev<wbr>el</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Pierre-Yves David<br>
</font></span></blockquote></div><br></div></div>