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