>
>
>>A couple weeks ago, someone was doing profiling on the code. It was
>>briefly claimed (and later discounted) that strlen() was causing a
>>noticeable slow-down. So, I went through the code base and looked at
>>each use of strlen() to find out if it was necessary. It turns out
>>the svn code is not doing very many excessive strlen calls. But there
>>are a few. Find below the first strlen optimization patches.
>>Probably, in the grand scheme of things, it's not worth doing this
>>optimization. However, since I've already done it, I say it should be
>>reviewed and applied. :-)
>>
>>
>
>Well, here's the review, and it should not be applied (except possibly
>the one correct change).
>
>
I don't think any of these changes should be noticeably faster. The
reason why strlen is showing up in your profile is not because strlen is
slow, but because the data strlen is examining probably does not reside
in the cache. If you optimize the strlen out, the slowdown should show
up in the function instead of strlen, and may give the appearance that
its faster, when in fact the whole execution time may not have changed.
>>+/* Returns 1 if A is longer than B, -1 if B is longer than A, and
>>+ * 0 if A and B are the same length.
>>+ *
>>+ * This is better than using (strlen(a) > strlen(b)) because only
>>+ * O(min(len(a), len(b))) chars are examined instead of O(len(a) +
>>len(b))
>>
>>
>>
Chances are this won't be much faster if at all, because a cacheline
usually can encompass the entire string. You may see some speed
increase with this, but if that occurs, the better way to fix this is to
fix apr's malloc alignment so the string resides entirely within a
cacheline.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 6 14:58:00 2002