Le Mardi 25 Octobre 2011 10:44:16 Stefan Behnel a écrit : > Richard Saunders, 25.10.2011 01:17: > > -On [20111024 09:22], Stefan Behnel 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 > > But also extremely likely to happen. This means that the strings are pure > ASCII, which is highly likely and one of the main reasons why the unicode > string layout was rewritten for CPython 3.3. It allows CPython to save a > lot of memory (thus clearly proving how likely this case is!), and it would > also allow it to do faster comparisons for these strings.
Python 3.3 has already some optimizations for latin1: CPU and the C language are more efficient to process char* strings than Py_UCS2 and Py_UCS4 strings. For example, we are using memchr() to search a single character is a latin1 string. Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
