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

Re: Cherry picking changes from the performance branch

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Mon, 06 Sep 2010 20:55:44 +0200

Hyrum K. Wright wrote:
> As I recall, Stefan recently declared the performance branch "done".
Correct. I've just been polishing parts of it over the last
two weeks or so.
> It's encouraging to see a few intrepid users and devs looking at the
> branch and providing feedback.
> Through IRC and other conversations, I've gotten the feeling that some
> of the changes made on the branch might be a bit too wide-spread to
> warrant whole-sale inclusion in 1.7, but several people have expressed
> interested in cherry picking at least some bits back to trunk. I've
> not yet done a comprehensive review of the changes on the branch, and
> would appreciate any suggestions folks may have of low-hanging,
> independent useful bits.
> For starters, I would consider:
> * the new svn_io_file_read_full2() API
> * the new svn_io_file_putc() API
> * the new svn_stringbuf_appendbyte() API
These are certainly good starters. Basically, all from io.c
should be easy to review and adopt in trunk.

Somewhat higher hanging but still within reach IMHO,
is the svn_stream_readline() implementation plus the
required stream API extensions. The complexity is very
low but the performance impact is significant.
> Note that I don't include the caching work, since I think it might be
> much more far-reaching, and probably needs more review before going
> into trunk.
If I was to pick a single change that I would want to
see in 1.7, it is the membuffer cache being used as
full-text cache. It does not require any of the serialization
stuff, fs_fs.c or dag.c changes. And it is the single most
beneficial change wrt. to server performance.

> The branch should also probably have a catch-up merge to prevent it
> from diverging too far. I'm happy to do so, as well as fix up any
> style nits which may exist on the branch. I'll do some digging to
> determine the various revision ranges to make the above suggestions
> merge to trunk, and post back.
Please do ... it spares me the pain to do it myself ;)

-- Stefan^2.
Received on 2010-09-06 20:56:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.