Re: Performance optimization - svn_stringbuf_appendbyte()

> New Revision: 997203
>
> URL: http://svn.apache.org/viewvc?rev=997203&view=rev
> Log:
> Merge r985037, r985046, r995507 and r995603 from the performance branch.
>
> These changes introduce the svn_stringbuf_appendbyte() function, which has
> significantly less overhead than svn_stringbuf_appendbytes(), and can be
> used in a number of places within our codebase.

Hi Stefan2.

I have been wondering about the actual benefit of such tightly
hand-optimized code. Today I got around to giving it a quick spin.

In my first test, it made no difference whatsoever, because the
optimized code is never executed. The recent merge r1002898 of r1001413
from the performance branch introduced a bug:

- if (str->blocksize > old_len + 1)
+ if (str->blocksize < old_len + 1)

which totally disables the optimized code path.

Fixed in r1005437.

That solved, a loop doing a million simple appendbyte calls runs more
than twice as fast as calling appendbytes(..., 1). That's fantastic.

But what about that hand-optimization? I wrote a simple version of the
function, and called it 'appendbyte0':

svn_stringbuf_appendbyte0(svn_stringbuf_t *str, char byte)
{
  if (str->blocksize > str->len + 1)
    {
      str->data[str->len++] = byte;
      str->data[str->len] = '\0';
    }
  else
    svn_stringbuf_appendbytes(str, &byte, 1);
}

Here are the results (see full patch attached):

Times: appendbytes appendbyte0 appendbyte (in ms)
run: 89 31 34
run: 88 30 35
run: 88 31 34
run: 88 30 34
run: 88 31 34
min: 88 30 34

This tells me that the hand-optimization is actually harmful and the
compiler does a 10% better job by itself.

Have I made a mistake?

What are the results for your system?

(I'm using GCC 4.4.1 on an Intel Centrino laptop CPU.)

- Julian