[Python-Dev] Re-introduce caching for _strptime.py for 2.3.1?
bac at OCF.Berkeley.EDU
Tue Aug 5 12:41: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.
More information about the Python-Dev