> >> Before going further with this, I'd suggest you have a look at your
> >> compiler settings.
> > 
> > They are set by the configure script:
> > 
> > gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> > -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
> > Objects/unicodeobject.o Objects/unicodeobject.c
> 
> Which gcc version are you using ?

$ gcc -v
Utilisation des specs internes.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-mageia-linux-gnu
Configuré avec: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --with-bugurl=http://bugs.mageia.org/
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release --enable-languages=c,c
++,ada,fortran,objc,obj-c++,java --build=x86_64-mageia-linux-gnu
--host=x86_64-mageia-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-objc-gc
--enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp
--disable-werror --with-ppl --with-cloog
--with-python-dir=/lib/python2.7/site-packages --enable-lto
Modèle de thread: posix
gcc version 4.5.2 (GCC) 

> Is it possible that you have -fno-builtin enabled ?

Why would it be enabled? It is not on the command line.

> >> Such optimizations are normally performed by the
> >> compiler and don't need to be implemented in C, making maintenance
> >> harder.
> > 
> > The fact that the glibc includes such optimization (in much more
> > sophisticated form) suggests to me that many compilers don't perform
> > these optimizations automically.
> 
> When using gcc, the glibc functions are usually not used at all,
> since gcc comes with a (rather large) set of builtins which are
> inlined directly, if you have optimizations enabled and inlining
> is found to be more efficient than calling the glibc function:

What would that change? Whether the optimized memchr() comes from gcc or
the glibc is not relevant here.

> There is: the compiler will have alignement information available and
> can also benefit from using registers instead of the stack, knowledge
> about processor cache lines, etc. Such information is lost when calling
> a function. The function call itself will also create some overhead.
> 
> BTW: You should not only test the optimization with long strings, but also
> with short ones (e.g. 2-15 chars) - which is a much more common case
> in practice.

With very short strings, the runtimes tend to be identical, which is
understandable.