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

Re: [Issue 1429] 'svn checkout' unbelievably slow compared to cvs

From: David Kimdon <dwhedon_at_debian.org>
Date: 2003-10-20 18:48:22 CEST

On Mon, Oct 20, 2003 at 09:19:18AM -0500, kfogel@collab.net wrote:
> dwhedon@tigris.org writes:
> > The profiles just attached correspond to r7437. In both cases I am
> > checking out the source of gnuplot-3.8j.0 (2072307 bytes gzipped).
> > For the ra_dav example apache is on the local machine. One
> > interpretation is that we are spending a lot of time on checkout
> > creating the vdelta. Since checkout is much like update for each
> > file we currently calculate a vdelta against nothing and send the
> > delta. I have a patch in the works that sends full text when we are
> > comparing against nothing rather than calculating the delta. It
> > looks like I will have some time this weekend, so maybe I'll even
> > get it done :-)
> Thanks, David! It's really nice to have more company on the profiling
> work...
> Just to make sure I understand what you're saying: you're talking
> about a change whereby we would manually construct vdelta windows that
> contain nothing but "fulltext" inserts, right? I.e., we'd still be
> producing vdelta windows, but instead of doing so by diffing against
> the empty string, we'd do it by building them directly.

exactly, patch posted last night, mixed results so far.

> I'm assuming this is your plan, because presumably, we can't just send
> raw fulltext -- the consumer is still expecting vdelta data, though it
> doesn't care how that data was produced, or whether any vdelta
> compression is happening (we get compression when we calculate against
> the empty string, but we won't get compression if we construct the
> windows by hand).

yup, and the lack of compression may be what is making clock time
similar or at least not as good as I was hoping when we send full text
(windows). I'll take a look a vdelta. Maybe we can have our cake and
eat it to. That is, maybe we can get vdelta compression without
needing to go through the whole algorithm if we know that our input is
an empty bytestream. That would give us a CPU speedup and wouldn't
clog the data channel. IIRC the consumer of vdeltas calculated based
on an empty byte stream was fast.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 20 18:58:16 2003

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.