homepage

> 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
> 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.
> I tested using memchr() when writing those "naive" loops.
memchr() is mentioned in another issue, #13134.
> memchr()
> is inlined by the compiler just like the direct loop
I don't think so. If you look at the glibc's memchr() implementation,
it's a sophisticated routine, not a trivial loop. Perhaps you're
thinking about memcpy().
> and the generated
> code for the direct version is often easier to optimize for the compiler
> than the memchr() one, since it receives more knowledge about the used
> data types.
?? Data types are fixed in the memchr() definition, there's no knowledge
to be gained by inlining.