Cherry picking changes from the performance branch

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

As I recall, Stefan recently declared the performance branch "done".
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

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.

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.

-Hyrum

Re: Cherry picking changes from the performance branch

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Mon, Sep 6, 2010 at 1:39 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> On Fri, Sep 3, 2010 at 11:19 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> As I recall, Stefan recently declared the performance branch "done".
>> 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
>>
>> 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.
>>
>> 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.
>
> Hearing nothing, I'll at least bring the branch up-to-date with trunk,
> and then go through the logs to find the relevant revisions for the
> above bits.

I've identified the first set of revisions: r985014, r985669, and
r987893.  These make more complete use of the svn_ctype_is* functions
throughout the code base.

On a more general note, I'm planning on reviewing the revisions and
then committing the merge (assuming all tests pass).  I invite folks
to review the various commit mails (which will hopefully be relatively
small).

-Hyrum

Re: Cherry picking changes from the performance branch

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Fri, Sep 3, 2010 at 11:19 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> As I recall, Stefan recently declared the performance branch "done".
> 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
>
> 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.
>
> 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.

Hearing nothing, I'll at least bring the branch up-to-date with trunk,
and then go through the logs to find the relevant revisions for the
above bits.

-Hyrum

Re: Cherry picking changes from the performance branch

[Stefan Fuhrmann <st...@alice-dsl.de>]

Hyrum K. Wright wrote:
> On Mon, Sep 6, 2010 at 1:55 PM, Stefan Fuhrmann
> <st...@alice-dsl.de> wrote:
>   
>> Hyrum K. Wright wrote:
>>     
>>
>>> 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. :)
>
>   
Just reviewed your first two commits and they don't seem
to affect any of my changes. I will look for places where
newer APIs can be used comming WE.

-- Stefan^2.

Re: Cherry picking changes from the performance branch

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Mon, Sep 6, 2010 at 1:55 PM, Stefan Fuhrmann
<st...@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. :)

-Hyrum

Re: Cherry picking changes from the performance branch

[Stefan Fuhrmann <st...@alice-dsl.de>]

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.