You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by André Malo <nd...@perlig.de> on 2003/08/03 01:17:15 UTC
[PATCH] locale independent apr_str_eq function
Well, I've started with a patch (attached). It works fine for me, but I'm not
sure with the naming at all. Any comments?
nd
[PATCH] rev#1 locale independent apr_str_eq function
Posted by André Malo <nd...@perlig.de>.
* André Malo wrote:
> Hmm, so now we can just rename apr_streq.c to apr_strcaseeq.c (dropping the
> simple eq functions), include the case tables only there (regarding to the
> other issue). The macros could stay in apr_lib.h (plus the apr_streq
> macros?), since one has to link against the apr anyway. The tables should
> probably be declared as APR_DECLARE_DATA then.
> Does this sound better?
for example this new patch? :)
nd
Re: [PATCH] locale independent apr_str_eq function
Posted by André Malo <nd...@perlig.de>.
* Joe Orton wrote:
> That benchmark is rigged :) It only compares against the strcmp in
> libc.so due to the missing #include <string.h>. I'd always bet on the
> inline asm over C code...
oh man, I'm dumb ;-)
Thanks.
> $ gcc -O2 -DINLINE -o streq streq.c && ./streq
> iterations: 1000000000
>
> [01/05] streq: 4 sec
> [02/05] streq: 4 sec
> [03/05] streq: 4 sec
> [04/05] streq: 4 sec
> [05/05] streq: 4 sec
> [average] streq: 4 sec
> [01/05] !strcmp: 2 sec
> [02/05] !strcmp: 3 sec
> [03/05] !strcmp: 3 sec
> [04/05] !strcmp: 3 sec
> [05/05] !strcmp: 2 sec
> [average] !strcmp: 2.6 sec
Well, would it still make sense to define an apr_str(n)eq macro for
consistency?
Hmm, so now we can just rename apr_streq.c to apr_strcaseeq.c (dropping the
simple eq functions), include the case tables only there (regarding to the
other issue). The macros could stay in apr_lib.h (plus the apr_streq
macros?), since one has to link against the apr anyway. The tables should
probably be declared as APR_DECLARE_DATA then.
Does this sound better?
nd
Re: [PATCH] locale independent apr_str_eq function
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sun, Aug 03, 2003 at 02:37:23PM +0200, André Malo wrote:
> * Joe Orton wrote:
>
> > I understand the need for a strcasecmp replacement, but are the
> > strcmp/!strcmp replacements just for consistency? On some platforms
> > strcmp is an optimised asm inline so unless there's a good reason to
> > tempt people away from strcmp I'd leave apr_streq/strneq out.
>
> Attached is a quick benchmark with very interesting results. Some other
> compiler tests would be helpful, of course.
> The main result of this one is: As long as the function is inlined and an
> optimizer is turned on, it's reasonably faster than strcmp.
That benchmark is rigged :) It only compares against the strcmp in
libc.so due to the missing #include <string.h>. I'd always bet on the
inline asm over C code...
$ gcc -O2 -DINLINE -o streq streq.orig.c && ./streq
iterations: 1000000000
[01/05] streq: 4 sec
[02/05] streq: 5 sec
[03/05] streq: 4 sec
[04/05] streq: 4 sec
[05/05] streq: 4 sec
[average] streq: 4.2 sec
[01/05] !strcmp: 16 sec
[02/05] !strcmp: 17 sec
[03/05] !strcmp: 19 sec
[04/05] !strcmp: 17 sec
[05/05] !strcmp: 16 sec
[average] !strcmp: 17 sec
You have new mail
$ diff -u streq.orig.c streq.c
--- streq.orig.c 2003-08-03 13:51:40.000000000 +0100
+++ streq.c 2003-08-03 13:52:36.000000000 +0100
@@ -1,6 +1,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
+#include <string.h>
#define LEN (1024 * 1024)
#define ITER (1000 * 1000 * 1000)
$ gcc -O2 -DINLINE -o streq streq.c && ./streq
iterations: 1000000000
[01/05] streq: 4 sec
[02/05] streq: 4 sec
[03/05] streq: 4 sec
[04/05] streq: 4 sec
[05/05] streq: 4 sec
[average] streq: 4 sec
[01/05] !strcmp: 2 sec
[02/05] !strcmp: 3 sec
[03/05] !strcmp: 3 sec
[04/05] !strcmp: 3 sec
[05/05] !strcmp: 2 sec
[average] !strcmp: 2.6 sec
Re: [PATCH] locale independent apr_str_eq function
Posted by André Malo <nd...@perlig.de>.
* Joe Orton wrote:
> I understand the need for a strcasecmp replacement, but are the
> strcmp/!strcmp replacements just for consistency? On some platforms
> strcmp is an optimised asm inline so unless there's a good reason to
> tempt people away from strcmp I'd leave apr_streq/strneq out.
Attached is a quick benchmark with very interesting results. Some other
compiler tests would be helpful, of course.
The main result of this one is: As long as the function is inlined and an
optimizer is turned on, it's reasonably faster than strcmp.
It's finally worth the effort, I think.
I'm wondering, how it would be as a shared lib, though.
nd
Re: [PATCH] locale independent apr_str_eq function
Posted by André Malo <nd...@perlig.de>.
* Joe Orton wrote:
> On Sun, Aug 03, 2003 at 01:17:15AM +0200, André Malo wrote:
>> Well, I've started with a patch (attached). It works fine for me, but I'm
>> not sure with the naming at all. Any comments?
>
> I understand the need for a strcasecmp replacement, but are the
> strcmp/!strcmp replacements just for consistency? On some platforms
> strcmp is an optimised asm inline so unless there's a good reason to
> tempt people away from strcmp I'd leave apr_streq/strneq out.
A good optimizer should do the same (perhaps I should do some benchmarks [1]).
Perhaps we should APR_INLINE the functions? But the advantages for a streq
interface would concern me more. The interface is better (more natural if you
wanna test strings for equality) and you don't take the overhead of the -1/1
decision.
If it's really slower than strcmp, we should at least
#define apr_streq(a,b) (!strcmp(a,b))
for the interface :)
> Adding the global arrays to apr_lib.h adds 512 bytes to every object
> file which includes that header, not sure that is a good idea, could
> result in noticeably bigger executables.
The linker should throw them away. But the alternative would be, however, to
put the new macros somewhere else. Where?
nd
[1] Hey, benchmarks during the build process would be cool -- and annoying
people ;-)
Re: [PATCH] locale independent apr_str_eq function
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sun, Aug 03, 2003 at 01:17:15AM +0200, André Malo wrote:
> Well, I've started with a patch (attached). It works fine for me, but I'm not
> sure with the naming at all. Any comments?
I understand the need for a strcasecmp replacement, but are the
strcmp/!strcmp replacements just for consistency? On some platforms
strcmp is an optimised asm inline so unless there's a good reason to
tempt people away from strcmp I'd leave apr_streq/strneq out.
Adding the global arrays to apr_lib.h adds 512 bytes to every object
file which includes that header, not sure that is a good idea, could
result in noticeably bigger executables.
Regards,
joe