strptime performance

John Roth newsgroups at
Tue Nov 4 12:28:57 CET 2003

"Delaney, Timothy C (Timothy)" <tdelaney at> wrote in message
news:mailman.407.1067911419.702.python-list at
> From: John Roth [mailto:newsgroups at]
> "George Trojan" <george.trojan at> wrote in message
> news:bo6oaf$vfq$1 at
> > Is time.strptime() intrinsically slow and should be avoided whenever
> > possible? I have the following code in my application:
> According to the "what's new in Python" for 2.3, the strptime
> implementation was switched from a lightweight wrapper
> around the frequently buggy and incompatible C library
> to a portable pure Python implementation.

Note also in 2.3.1 (and later) ...

"Caching in has been re-introduced. This leads to a large
performance boost at the cost of not being thread-safe from locale changes
while executing time.strptime()".

> Yes, it's going to be a lot slower.

Now that's an assumption you shouldn't be making until you've timed it.

[John Roth]
Let me put it this way. If a pure Python implementation is even
close to a C language implementation, then the C language
implementation has to be truely awful (as in awe-inspiringly bad).
As you note above, caching was (re) introduced to get a
performance boost. Sometimes you can make a performance
statement without measurement with a high expectation of being

John Roth

Tim Delaney

More information about the Python-list mailing list