strptime performance

[John Roth]

"Delaney, Timothy C (Timothy)" <tdelaney at avaya.com> wrote in message
news:mailman.407.1067911419.702.python-list at python.org...
> From: John Roth [mailto:newsgroups at jhrothjr.com]
>
> "George Trojan" <george.trojan at noaa.gov> wrote in message
> news:bo6oaf$vfq$1 at news.nems.noaa.gov...
> > 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 _strptime.py 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
right.

John Roth

Tim Delaney