Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu
<mailto:hyrum_wright_at_mail.utexas.edu?Subject=Re:%20svn%20commit:%20r985037%20-%20in%20/subversion/branches/performance/subversion:%20include/%20libsvn_client/%20libsvn_diff/%20libsvn_fs_fs/%20libsvn_ra_svn/%20libsvn_repos/%20libsvn_subr/%20libsvn_wc/%20svn/%20svndumpfilter/%20tests/libsvn_subr/>>
wrote:
On Thu, Aug 12, 2010 at 6:27 PM, <stefan2_at_apache.org> wrote:
/> Author: stefan2 /
/> Date: Thu Aug 12 23:27:40 2010 /
/> New Revision: 985037 /
/> /
/> URL: http://svn.apache.org/viewvc?rev=985037&view=rev
<http://svn.apache.org/viewvc?rev=985037&view=rev> /
/> Log: /
/> The second (and probably last) mass change:
svn_stringbuf_appendbytes has /
/> a relatively large runtime overhead if we only add single bytes -
which happens /
/> frequently in svn's parser codes. /
/> /
/> Therefore, add a specialized and simpler variant that takes exactly
one character /
/> and use it in any suitable place. /
Instead of introducing a completely new API, what would be the
implications of just checking for the single-byte case inside of
svn_stringbuf_appendbytes(), and calling the more specialized version
in that case?
If we can internally make the decision automatic for API consumers, I
think that's a win.
The issue here is that adding a single char is such a small
operation that any overhead will hurt. Reasons to keep
the extra API:
* passing a char to a function is a register transfer, passing
a char* pointer prevents the caller from keeping it in a register.
* the shorter signature reduces register pressure
* it is a small enough function that the compiler might inline it
Just to be sure I looked at the code generated by VisualC++
and GCC committed an even improved version in r995603.
-- Stefan^2.
