[PATCH RFC] wireproto: add support for batching of some commands

[Matt Mackall]

On Wed, 2011-03-16 at 17:02 +0100, Peter Arrenbrecht wrote:
> On Wed, Mar 16, 2011 at 3:31 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Wed, 2011-03-16 at 12:45 +0100, Peter Arrenbrecht wrote:
> >> On Mon, Mar 14, 2011 at 7:44 PM, Matt Mackall <mpm at selenic.com> wrote:
> >> > On Mon, 2011-03-14 at 10:07 +0100, Peter Arrenbrecht wrote:
> >> >> # HG changeset patch
> >> >> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
> >> >> # Date 1300093067 -3600
> >> >> wireproto: add support for batching of some commands
> >> >>
> >> >> Allows clients to send batches of server commands in one roundtrip. An
> >> >> example is provided in the contained test.
> >> >>
> >> >> This is desirable for the new discovery protocol. For example, in a later
> >> >> patch we will batch the request for the server's heads with the one where
> >> >> the server checks if it knows the client's heads, eliminating one roundtrip
> >> >> out of 4 for a pull where local is a subset of remote.
> >> >
> >> > It'd be really nice if you explained how it worked. There's a lot here I
> >> > don't understand.
> >> >
> >> > I can't find the part where the batched command automatically falls back
> >> > to serial commands so that client code doesn't have to implement
> >> > fallback on its own.
> >>
> >> Matt, good point. This approach introduces separate code paths which
> >> make good test coverage harder. I'll post a better patch soonish.
> >>
> >> In a similar vein, the current prototype work for new discovery treats
> >> local and remote repos differently. For local repos, it simply
> >> computes the set of common heads directly, since it has access to both
> >> graphs in full. But this would probably mean we'd have to run the test
> >> suite in its entirety for both local and for remote behaviour (à la
> >> --pull). Much like we currently have a flag for tests with inotify
> >> active. Does not make me happy.
> >
> > Yeah, this may be too clever. How much CPU time are we talking about?
> 
> Depends on repo size. Mainly caused by inverting the graph.

Going from a parent-oriented graph to a child-oriented one? Hrmm. That
shouldn't take seconds. I've also found that a fair number of algorithms
(though certainly not all) that seem like they should naturally operate
on children can actually be tweaked to operate on parents.

-- 
Mathematics is the supreme nostalgia of our time.