gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jason McCarty
Subject: Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes
Date: Sat, 31 Jan 2004 15:29:38 -0500
User-agent: Mutt/1.5.4i

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. 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.

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). Since a smart server can record and recall
what it's done, it should have an easier (faster) time traversing the
revision graph to find summaries than in the original summary-delta
proposal.

> 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, 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.

-- 
Jason McCarty <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]