httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe JAILLET <>
Subject Re: strncasecmp
Date Mon, 23 Nov 2015 20:12:30 GMT
Hi Jim,

Do you have done some benchmark and have results to share?

I tried to do some but the benefit of the optimized version is not that 
clear, at least on my system:
    gcc 5.2.1
    Linux linux 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux

I've tried to trick gcc in order to avoid some optimization. (gcc does 
its best to remove/inline/remove from loop known standard C functions)
I've check asm output to be more confident on the code generated by gcc.

Based on my own results only, and without any becnhmark, I would -1 a 
For small strings (below identical char), your implementation looks 
faster, but above 4 identical chars it looks slower

I can provide my test program if interested.

best regards,

Le 20/11/2015 19:53, Jim Jagielski a écrit :
> Implemented in r1715401
> If people want to nit-pick about naming and wish to
> rename it to something else, be my guest.
>> On Nov 20, 2015, at 1:03 PM, Yann Ylavic<>  wrote:
>> +1
>> On Fri, Nov 20, 2015 at 6:17 PM, Jim Jagielski<>  wrote:
>>> We use str[n]casecmp quite a bit. The rub is that some
>>> platforms use a sensible implementation (such as OSX) which
>>> uses a upper-lowercase map and is v. fast, and others
>>> use a brain-dead version which does an actual tolower() of
>>> each char in the string as it tests. We actually try to
>>> handle this in many cases by doing a switch/case test on the
>>> 1st char to fast path the strncasecmp, resulting in ugly code.
>>> This is crazy.
>>> I propose a ap_strncasecmp/ap_strcasecmp which we should use.
>>> Ideally, it would be in apr but no need to wait for that
>>> to happen :)
>>> Unless people have heartburn about this, I will add next week.

View raw message