This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients BreamoreBoy, benjamin.peterson, ezio.melotti, jcea, kushal.das, loewis, pitrou, serhiy.storchaka, terry.reedy, thomaslee, vstinner
Date 2013-04-03.20:00:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1365019257.68.0.403906108897.issue16061@psf.upfronthosting.co.za>
In-reply-to
Content
My experiments last September, before this was filed, showed that str.find (index) had most of the relative slowdown of str.replace. I assumed at that time that .replace used .find or .index to find  substrings to replace, so that the fix for .replace would include speeding up .find/index. Looking at the patches, I see that I was wrong; I guess because .replace copies as it goes. I will open a separate issue sometime unless .find gets fixed here.

For both .find and .replace, the regression was worse on Windows than on linux, so the patches should be tested on Windows also. If I can get vc++ express 2008 installed and working on my current substitute machine. I will give them a try.
History
Date User Action Args
2013-04-03 20:00:57terry.reedysetrecipients: + terry.reedy, loewis, jcea, pitrou, vstinner, thomaslee, benjamin.peterson, ezio.melotti, BreamoreBoy, serhiy.storchaka, kushal.das
2013-04-03 20:00:57terry.reedysetmessageid: <1365019257.68.0.403906108897.issue16061@psf.upfronthosting.co.za>
2013-04-03 20:00:57terry.reedylinkissue16061 messages
2013-04-03 20:00:57terry.reedycreate