On 8/18/2012 5:27 PM, Antoine Pitrou wrote:
> 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:
Just curious, what system?
>
> $ 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.
The current default 'number' of 1000000 is higher that I remember. Good
to know.
>> 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).
It is not in my 3.3.0b2 windows install, but I have heard of it. Another
good reminder. My main interest was in refuting '3.3 strings ops are
always slower'. Both points above are also good 'ammo'. I am sure this
discussion will re-occur after the release.
--
Terry Jan Reedy
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