[OPEN-ILS-DEV] PATCH: utils.[ch] (new function buffer_add_n())

[Scott McKellar]

These patches add a new function buffer_add_n(), and the corresponding
function-like macro OSRF_BUFFER_ADD_N.  These facilities append a
specified number of characters from an input string to a growing_buffer.
They are intended for situations where the length of the input string
is already known, or where the input string is not nul-terminated in the
right place.

-----------------

The motivation for these patches is some code in transport_session.c
that needs to append a known number of characters from an XML string to
a growing_buffer.  Since it needs only part of the input string, it uses
strncpy() to copy the characters to an intermediate buffer, and then
calls buffer_add().  With the new function or macro, we can eliminate
strncpy(), along with the strlen() inside buffer_add().

I wrote a benchmark program, where the code using buffer_add() or 
OSRF_BUFFER_ADD uses an intermediate buffer as described above.  The 
growing_buffer was pre-allocated so that it wouldn't need to be expanded.
Under these conditions the new macro was about three times as fast as 
the old function.

For either the old or the new versions, the macro was only a few percent
faster than the corresponding function.  This comparison is presumably
sensitive to the size of the appended string: the shorter the string,
the more the macro helps, relatively.  My benchmark added a
string of 26 characters.

In a case where the intermediate buffer is not necessary because the
input string is appropriately nul-terminated, but its length is already
known, I would expect the new version to be about twice as fast due to 
the elimination of a strlen().  However I haven't benchmarked that
comparison.

This is not a case of premature optimization, because the existing code
is already mature.  It may be a case of *immature* optimization, because
the cycles saved will be a drop in the bucket compared to the other
overhead involved in processing an incoming Jabber message.  However
the use of buffer_add_n() will not make the code more complicated or
harder to read, so even a slight speedup will be worth having.

Scott McKellar
http://home.swbell.net/mck9/ct/

Developer's Certificate of Origin 1.1 By making a contribution to
this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated
in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source license
and I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and

(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record
of the contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely and may
be redistributed consistent with this project or the open source
license indicated in the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utils_h_9.patch
Type: text/x-patch
Size: 1081 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081213/44727055/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utils_c_12.patch
Type: text/x-patch
Size: 875 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20081213/44727055/attachment-0001.bin