[Python-Dev] 3.3 str timings (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sat Aug 18 23:27:58 CEST 2012

On Sat, 18 Aug 2012 17:17:14 -0400 Terry Reedy <tjreedy at udel.edu> wrote:

The issue came up in python-list about string operations being slower in 3.3. (The categorical claim is false as some things are actually faster.) Some things I understand, this one I do not.

Win7-64, 3.3.0b2 versus 3.2.3 print(timeit("c in a", "c = '…'; a = 'a'*1000+c")) # ord(c) = 8230 # .6 in 3.2, 1.2 in 3.3

I get opposite numbers:

$ python3.2 -m timeit -s "c = '…'; a = 'a'*1000+c" "c in a" 1000000 loops, best of 3: 0.599 usec per loop $ python3.3 -m timeit -s "c = '…'; a = 'a'*1000+c" "c in a" 10000000 loops, best of 3: 0.119 usec per loop

However, in both cases the operation is blindingly fast (less than 1µs), which should make it pretty much a non-issue.

Why is searching for a two-byte char in a two-bytes per char string so much faster in 3.2? Is this worth a tracker issue (I searched and could not find one) or is there a known and un-fixable cause?

I don't think it's worth a tracker issue. First, because as said above it's practically a non-issue. Second, given the nature and depth of changes brought by the switch to the PEP 393 implementation, an individual micro-benchmark like this is not very useful; you'd need to make a more extensive analysis of string performance (as a hint, we have the stringbench benchmark in the Tools directory).

This is one of the 3.3 improvements. But since the results are equal: ('a'*1000).encode() == ('a'*1000).encode(encoding='utf-8') and 3.3 should know that for an all-ascii string, I do not see why adding the parameter should double the the time. Another issue or known and un-fixable?

When observing performance differences, you should ask yourself whether they matter at all or not.

Regards

Antoine.

-- Software development and contracting: http://pro.pitrou.net

More information about the Python-Dev mailing list