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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4