On 27/09/2012 20:08, Terry Reedy wrote:
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.
http://bugs.python.org/issue16061 and you should read it. I've tried to
really muddy the waters by opening this issue, and the python devs are
giving out facts, how dare they!!! It's just not my day is it? :(
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
