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

Re: Why is subversion so slow?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-04-09 22:51:46 CEST

Michael Price <mprice@atl.lmco.com> writes:

> Ben Collins-Sussman wrote:
> > Thomas Lohmueller <thomas@lohmueller.ch> writes:
> >> The problem is neither client nor server disk-io. It looks like
> >> subversion sends much more data over the wire.
> > How do you make that conclusion? I have always believed, and still
> > believe, that the culprit is libsvn_wc doing way too many disk-i/o
> > activities.
> I would agree with that assessment.

Here's a very revealing piece of data.

The way 'svn export' currently works is to do an 'svn checkout', then
recursively destroy all .svn directories.

A few weeks back, gstein and I thought how much faster 'svn export'
would be if we wrote a custom "editor" vtable that simply dumped data
to disk -- in other words, completely bypassing all of the accounting
that libsvn_wc does in the .svn area.

So I wrote a tiny editor to do that. Sure enough, an export of
Subversion's own trunk sped up by a factor of 4! (See issue #1230)

Then I made my editor notice the svn:eol-style property. Instead of
just doing a 'mv tmpfile file' on each file, the editor now calls
'svn_subst_copy_and_translate (tmpfile, file)', changing line endings
in the copy.

And now there's basically no difference in speed at all... maybe a 5%
speed increase at most. (!)

On the one hand, I should probably chuck my export editor out the
window, since it has proven fruitless. On the other hand, I think
there's a big clue here about why 'svn checkout' might be so slow.
It's doing the same thing: copy-and-translate on every received file.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 9 22:53:01 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.