Antoine Pitrou <pit...@free.fr> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13136> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
