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
--
http://mail.python.org/mailman/listinfo/python-list
