[Top][All Lists]

[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: Aaron Bentley
Subject: Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes
Date: Sat, 31 Jan 2004 16:21:50 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

Jason McCarty wrote:

Aaron Bentley wrote:

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


reply via email to

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