Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes

[Aaron Bentley]

Jason McCarty wrote:

> Aaron Bentley wrote:
>  
>
> > http://mail.gnu.org/archive/html/gnu-arch-users/2003-09/msg01419.html
> >
> > Looks like.  5x to 25x speedups and half the size for "summary deltas" 
> > of 200 KiB does sound worthwile.  My concern is that the speedup on the 
> > client side might be produced by pushing that CPU cost onto the server. 
> >    
>
> It would take server CPU time to create summaries in the first place,
> which is pure overhead on the server; however, a summary can be cached
> once created. 
Indeed, and that's an important advantage.  I thought Tom was proposing 
to satisfy DELTA requests by mergine the individual revision changesets 
on the server.  Unlike summary deltas, that pushes the compose_changeset 
CPU cost from the client onto the server, instead of reducing the net 
CPU cost.

But working from the summary deltas actually reduces the 
compose_changeset cost, which is nifty.

> Afterwards, you can make a tradeoff between the client and
> server CPU time, by composing none, some, or all of the deltas on the
> server and the rest on the client. This is feasible since Tom's DELTA
> proposal allows the server to send back a delta in multiple pieces.
>  
That's also pretty.

> Orthogonally, you can make a (client + server time) vs (server
> diskspace) tradeoff by caching more or fewer summaries on the server, in
> a hierarchical decomposition. E.g., if a version contains 1024 patches
> (a nice round number ;-), you can have
>
>                             summary-0-1024
>       summary-0-512,                               summary-512-1024
> summary-0-256   summary-256-512             summary-512-768    summary-768-1024
>                                   ...
>                                    :
>
> So depending on how much disk you're willing to burn, you can bound the
> number of deltas sent for a given DELTA command to around
> log2(#patches in version). 
>  
You can also implement the caching/composing logic as part of an archd 
proxy.  I can imagine
more free-form caching,
e.g. server gets the following requests: 0-39, 0-32, 0-50, 0-60
After these, server retains summary deltas for 0-32, 32-50.  Or is that 
0-32, 32-39, 39-50?  Or what about 0-39, 39-32, 39-50?

This could get baroque pretty easily, but it would allow lots of room 
for tuning.

> > Do we know that composing changesets will be significantly cheaper?  If 
> > they are, we should be doing it client-side too.
> >    
>
> I don't have any guess on that, 
My guess is that it will be cheaper in I/O bandwidth.  I believe diffs 
can have redundant hunks, so (in the absense of renames) all you need to 
do to combine them is concatenate them.  That should save CPU time.

> but even if it's not cheaper, it could
> still be worthwhile to precalculate and cache summaries server-side,
> since applying them _is_ significantly cheaper.
>  
No argument here.

Aaron