[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 1380 - trunk/subversion/include trunk/subversion/libsvn_fs

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-27 02:53:50 CET

On Tue, Feb 26, 2002 at 05:15:50PM -0800, Colin Putney wrote:
>...
> I suspect that this is actually aimed at optimizing streamy writes.

Yup!

> Consider the case of writing a 400K string into the database using 100K
> buffers. The database operations will go something like this:
>...
> It just gets worse and worse as the file size increases, and all of it
> goes into the logs.

My suspicion also.

> If you break the data into multiple records, you can just create a new
> record for each bufferful of data and tack it onto the end.

Yup. That is what "duplicate keys" are all about.

> An analogy would be reading data from a file into memory. You could call
> realloc() before every read to make room for the incoming data, but it's
> way better to create a linked list of buffers.

Yessir!

> I don't really know how BDB is implemented, so they might have some
> clever way of minimizing the hit for appending data to a record, but
> this is probably why your log files ballooned so much.

Yup yup...

Great articulation, Colin! My thoughts exactly. My IPC just broke down
between the brain and the mouth/email-typing.

I'm implementing the duplicate key thing right now to try it out. When I get
it working, I'll send out a patch. I've got maybe another 30 minutes
available to work, so I'll probably miss that. So that means, the patch will
come late tonite (3am pst, about 9 hrs from now).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:10 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.