Greg Hudson wrote:
>I had no idea that ra_dav was using appreciably more connections than
>ra_svn. Every time I've looked at the code, it looks like it opens two
>sessions in ra_lib->open and continues to reuse them. Is the repeated
>reconnecting being done inside neon?
>
>If that's not the source of the problem, I have an idea for narrowing it
>down. Do a tcpdump of a Subversion operation with timestamps. Using
>the timestamps, find out whether most of the time is spent in the client
>or in the server, and if there are particular steps of the operation
>which require lots of time.
>
>On Tue, 2003-02-11 at 13:37, Branko Čibej wrote:
>
>
>>Besides, sending deltas for checkout and import is total nonsense.
>>
>>
>
>It's not total nonsense; it's a space versus time issue. If we're
>spending 10% of import time in vdelta(), then eliminating checkout and
>import deltas will only speed up imports by about 10%, and at some cost
>in bandwidth. And computers will get faster more quickly than bandwidth
>will get cheaper.
>
Oh, but I think mod_deflate can do better than vdelta as far as
compression is concerned (well, slightly better); of course, ra_svn
doesn't have its mod_deflate; hm, perhaps we should just use zlib with
ra_svn, to get comparable throughput?
>>The fix is not speeding up vdelta (bet: you won't get a 2x speedup
>>anyway), but to remove it from the checkout and import code path
>>entirely.
>>
>>
>
>But speeding up vdelta will also help updates. But you're probably
>right; short of hand-coded assembly, we can probably only make small
>improvements, like inlining svn_txdelta__insert_op.
>
>
Yes, and a smart compiler probably already does that.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 11 20:32:19 2003