[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 6 Sep 2010 14:04:47 -0500

On Mon, Sep 6, 2010 at 1:55 PM, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:
> 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.

Good to know, those are the types of changes I'm looking for (initially).

>> 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 ;)

No problem. But please do look over my shoulder to ensure I don't
botch the conflict resolutions too badly. :)

Received on 2010-09-06 21:05:26 CEST

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