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

Re: svn commit: rev 1912 - trunk/subversion/include trunk/subversion/libsvn_subr trunk/subversion/libsvn_repos

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-12 06:30:09 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> On Sat, 2002-05-11 at 12:48, Ben Collins-Sussman wrote:
> > Well, I'm certain that we want our dumper and loader to operate on
> > generic svn_stream_t's. We want maximum flexibility.
> Why?

Purely on faith that gstein had a purpose in mind when he requested
streams instead of apr_file_t's. I think he imagines that someday we
can do dumps or loads over network pipes or something.

> > We certainly *could* write a buffered stream_t, but at the moment, I
> > don't think we have a real problem. The stream being read by the
> > loader is usually a stdio FILE * anyway, which means the operating
> > system is already buffering for us, no?
> Sure, there's buffering going on before we hit the actual system call
> layer. But for each byte in the dump file, you're performing a function
> call (svn_stream_read), a function call through a pointer (the stream's
> read function), and another function call (fread), with a certain amount
> of extra gook in each. Since dump files are large, I imagine that will
> add up to a lot of cycles.

Hmmm, true.

However -- the "slow" readline functionality is really only being used
to read header blocks and property lists. And these things, I reckon,
only make up maybe 10% of the data in a dumpstream. The other 90% of
it is fulltexts, which we're slurping up in huge chunks of 102K at a

And indeed, I don't notice any outrageous slowness. Earlier today, I
tried doing this:

  $ svnadmin dump repo-bkp-1840 | svnadmin load newrepo

And it got about 100 revisions in pretty quickly. The speed seemed
quite fast.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 12 06:33:24 2002

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.