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
backport.
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,
CJ
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<ylavic....@gmail.com> wrote:
+1
On Fri, Nov 20, 2015 at 6:17 PM, Jim Jagielski<j...@jagunet.com> 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.
