On Tue, Nov 14, 2000 at 11:21:27AM +1100, Martin Pool wrote:
> On 13 Nov 2000, Nicolas Williams <[EMAIL PROTECTED]> wrote:
>
> > A re-write would be good. Make the new protocol modular. Make rsync
> > itself modular. By modular I mean that delta engines, compression,
> > authentication, authorization, session integrity and privacy protection
> > and, lastly, file list building and/or filtering should all be
> > replaceable in a modular way. The last bit is most important from the
> > point of view of feature extension requests that have been seen on this
> > list.
>
> Modularity tends to trade off against performance. Since the whole
> point of rsync is to improve performance[0], this is something that
> must be approached carefully. People can get very fine-grained
> control at the moment by wrapping rsync in a $language script that
> finds files and runs rsync on each individually to deliver it to the
> right place; however that's much slower than sending everything over a
> single connection.
>
> ([0] Compared to transferring tarballs over scp.)
>
> It's not impossible to be modular and fast, it's just much harder than
> doing either one independently.
I disagree. Rsync's performance improvement stems from the rsync
delta algorythm, NOT from not being modular. Modularity means not much
more than a single level of function call indirection, and I doubt that
CPU cycles wasted there could destroy rsync's delta algorythm
advantage.
Have you profiled rsync? Where are its speed bottelnecks?
And if modularity is a performance issue, then forget session
encryption. Or is it that once you add the overhead of encryption
rsync's edge over SCP evaporates? If so, why bother with rsync over SSH?
I bet that any bottlenecks are likely to be in:
- the network (slow/congested) links
- disk/file system performance (can you read/write those files fast enough?)
- delta/compression computations (i.e., CPU cycles)
Again, I can't imagine that the CPU cycles spent in an indirect
function lookup would add up to the speed advantage of
delta/compression computations over not computing deltas at all!
Again, IMHO, or NSHO.
:)
> --
> Martin Pool, Linuxcare, Inc.
> +61 2 6262 8990
> [EMAIL PROTECTED], http://www.linuxcare.com/
> Linuxcare. Support for the revolution.
Nico
--
