[Python-Dev] memcmp performance (original) (raw)

Richard Saunders richismyname at me.com
Tue Oct 25 01:17:55 CEST 2011

-On [20111024 09:22], Stefan Behnel (stefan_ml at behnel.de) wrote:

I agree. Given that the analysis shows that the libc memcmp() is  particularly fast on many Linux systems, it should be up to the Python  package maintainers for these systems to set that option externally through  the optimisation CFLAGS.

Indeed, this is how I constructed my Python 3.3 and Python 2.7 : setenv CFLAGS '-fno-builtin-memcmp' just before I configured.

I would like to revisit changing unicode_compare: adding a  special arm for using memcmp when the "unicode kinds" are the  same will only work in two specific instances:

(1) the strings are the same kind, the char size is 1     * We could add THIS to unicode_compare, but it seems extremely       specialized by itself

(2) the strings are the same kind, the char size is >1, and checking     for equality     * Since unicode_compare can't detect equality checking, we can't       really add this to unicode_compare at all

The problem is, of course, that memcmp won't compare for less-than or greater-than correctly (unless on a BIG ENDIAN machine) for char sizes of 2 or 4.

If we wanted to put memcmp in unicodeobject.c, it would probably need to go into PyUnicode_RichCompare (so we would have some more semantic information).  I may try to put together a patch for that, if people think that's a good idea?  It would be JUST adding a call to memcmp for two instances specified above.

From: Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> In the same stretch, stuff like this needs to be documented. Package maintainers cannot be expected to follow each and every mailinglist's posts for nuggets of information like this. Been there, done that, it's impossible to keep track.

I would like to second that: the whole point of a Makefile/configuration file is to capture knowledge like this so it doesn't get lost.

I would prefer the option would be part of a standard build Python distributes, but as long as the information gets captured SOMEWHERE  so that (say) Fedora Core 17 has Python 2.7 built with -fno-builtin-memcmp,  I would be happy.

  Gooday,

  Richie

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20111024/5c4355b8/attachment.html>

More information about the Python-Dev mailing list