[Python-Dev] Re-introduce caching for _strptime.py for 2.3.1?

Raymond Hettinger python at rcn.com
Tue Aug 5 19:56:35 EDT 2003


> Bug #780807 is a complaint that strptime is now 1,200 times slower than 
> a C library version the user used to have.  Now slowdown is going to 
> happen since Python string code can't compete with C string code, let 
> alone _strptime has to figure out the locale info it needs while a C 
> version has direct access.  And I am sure people who now have strptime 
> on their platform are not going to complain about performance.  =)
> 
> But 1,200 times is a little high.  The new version I checked into HEAD 
> is supposedly only 3 times slower than the equivalant C version 
> according to the bug report submitter.  This is mainly because of caching.
> 
> My question is whether I should backport any of this.  The new version 
> of _strptime is thread-safe and has caching (2.3 is already thread-safe 
> thanks to the loss of caching for that version).  If I were to 
> re-introduce caching (which was in 2.3 until a day before 2.3.0c2) I 
> would need to also tweak other code to keep it thread-safe.  In other 
> words I would have to do more work than just throw back in the caching 
> code with the addition of a thread lock.
> 
> Is this considered a bugfix?  The only reason I question whether it is 
> since it is not a pure "bugfix" is because I know at least Raymond 
> thought the code should have gone back in before 2.3.0 final went out. 
> Had I not been so panicked about fixing that one bug the caching code 
> would still be in there and I would be patching 2.3.1 to make it 
> thread-safe instead of sending out this email.

I'm strongly in favor of re-introducing this code:

* it is the way you designed it in the first place
* it makes a huge performance difference
* the code was tested with it and when through beta and rc1
   without a problem (there was an unrelated bug elsewhere).
* I'm more confident in the code before it was "ripped out"
   at the last minute.
* There is no compelling reason to have to wait another 18
   months to have the code behave reasonably
* the is no real impact on the API as released

I'm +0 on tweaking it further to make it thread-safe.  IMO that
is a separate issue (possibly important but having no bearing 
on whether caching should be included).


Raymond Hettinger

#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################



More information about the Python-Dev mailing list