Article on the future of Python
Terry Reedy
tjreedy at udel.edu
Thu Sep 27 15:08:50 EDT 2012
On 9/27/2012 5:33 AM, Steven D'Aprano wrote:
> Nevertheless, I think there is something here. The consequences are nowhere
> near as dramatic as jmf claims, but it does seem that replace() has taken a
> serious performance hit. Perhaps it is unavoidable, but perhaps not.
>
> If anyone else can confirm similar results,
I already did, about a month ago, for windows. I think the actual
problem is with find, not replace (which does a find before the
replace). When I asked on pydev, Victor Stinner had no explanation, but
said he might look into it eventually. Others thought it not terribly
important since 7 times blazingly fast is still fast (in your example,
29 versus 3 microseconds per operation.
jmf wrapping a possible real issue with anti-3.3 crud did not help in
getting attention to the regression.
I also reported results of running stringbench.py on both 3.2 and 3.3 on
windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as
3.2. Find/replace is the notable exception in stringbench, so it is an
anomaly. Other things are faster in 3.3.
> I think this should be raised as a performance regression.
I agree, and Mark did it.
--
Terry Jan Reedy
More information about the Python-list
mailing list