[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: caching proxies and SVN network perf

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-02 00:21:51 CET

On Tue, Oct 24, 2000 at 08:14:51AM -0500, Karl Fogel wrote:
> May I just say: worrying about the interaction of svndiff with gzip,
> and the relative merits of using one or the other, is premature. In

Well, I'll take some blame for bringing up how we could use gzip in the
protocol :-) ... Mostly, I wanted to discuss some of our options to dispell
any notions that our decision to use HTTP/DAV is not necessarily going to
make us worse than CVS.

> the immortal words of Knuth (sometimes attributed to Dijkstra):
>
> "Premature optimization is the root of all evil."

Agreed. And the reason why it is evil? I'll offer my own quote on
optimization here: "90% of the time, you're wrong about where you spend 90%
of your time." [IOW, you optimize the wrong part of your code]

:-)

>
> Don't worry about it. IMHO, use svndiff for everything right now, if
> that's most convenient, even initial checkouts/checkins. Let the
> people doing the transport layer try gzipping it and see if they get
> improvement. If Subversion sometimes ineffectively tries to compress
> non-redundant data, it's not the end of the world. The time to
> squeeze every last drop out of the network performance is in the
> future.

Oh, we still have a good ways before trying that. We've got some "platform"
pieces to finish first: gzip support in both Neon and Apache (w.r.t always
being available and handy).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:13 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.