Julian Foad wrote:
> Branko Čibej wrote:
>
>> Jesper Louis Andersen wrote:
>>
>>> The patch simply works by making i an apr_size_t, increasing it
>>> and making the calculation str->len - i instead. Note that str->len
>>> is loop invariant and str->len - i can be common subexpression
>>> eliminated. Thus the performance drop should not be measureable.
>>>
>> Ah, but whilst "len - i" can be CSE'd, it cant' be avoided. You can
>> avoid the slowdown by continuing to use a countdown loop but shifting
>> the limits, thusly:
>
>
> Good, but why are we writing this function out long-hand and not just
> calling standard strrchr() and subtracting the start pointer from its
> result (if non-null)? We can reasonably expect strrchr() to be
> implemented efficiently for the platform on which it is running, and
> it may do better than our generic version.
strrchr must scan the string forwards first, and must always scan the
whole string. We already know the length of the string and can scan
backwards and stop at the first occurrence of the character. Also, while
strrchr could concievably optimise memory access by reading whole words
at a time, in practice I don't think the difference would show up for
short strings.
I guess we could argue backwards and forwards and produce numbers that
support both positions, while compilers get smarter and smarter... but I
don't think it's worth it. Let's just fix the signedness issue you
found, and leave it at that.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 14 19:09:28 2004