Re: svn commit: r997203 - in /subversion/trunk: ./ subversion/include/ subversion/libsvn_client/ subversion/libsvn_diff/ subversion/libsvn_fs_fs/ subversion/libsvn_ra_svn/ subversion/libsvn_repos/ subversion/libsvn_subr/ subversion/libsvn_wc/ subvers

On Wed, Sep 15, 2010 at 9:45 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Sep 15, 2010 at 06:52:07AM -0000, hwright_at_apache.org wrote:
>> ==============================================================================
>> --- subversion/trunk/subversion/include/svn_string.h (original)
>> +++ subversion/trunk/subversion/include/svn_string.h Wed Sep 15 06:52:06 2010
>> @@ -253,6 +253,15 @@ svn_stringbuf_chop(svn_stringbuf_t *str,
>>  void
>>  svn_stringbuf_fillchar(svn_stringbuf_t *str, unsigned char c);
>>
>> +/** Append a single character @a byte onto @a targetstr.
>> + *
>> + * reallocs if necessary. @a targetstr is affected, nothing else is.
>> + * @since New in 1.7.
>> + */
>> +void
>> +svn_stringbuf_appendbyte(svn_stringbuf_t *targetstr,
>> +                         char byte);
>> +
>
> The docstring should list advantages svn_stringbuf_appendbyte(buf, c)
> has over svn_stringbuf_appendbytes(buf, &c, 1). We need to understand
> where the performance benefits really come from. IIRC the benefit was
> dependent on the optimizer in the compiler to some extent, is this correct?

I don't think that's completely correct, but I'll leave it to Stefan
F. to determine that.

Since this function has now been merged to trunk, updates to the doc
string should be done on trunk. But I feel comfortable allowing
Stefan to make these docstring edits and commit without prior review,
instead of requiring him to mail the patch to the list.

-Hyrum
Received on 2010-09-15 09:56:59 CEST