strptime() in _strptime.py vs lib-dynload/time.so

[igor.tatarinov at gmail.com]

On Dec 17, 8:01 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Mon, 17 Dec 2007 01:53:24 -0300, <igor.tatari... at gmail.com> escribió:
>
> > On Dec 16, 8:47 pm, igor.tatari... at gmail.com wrote:
> >>    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
> >>     57765    6.020    0.000   12.970    0.000
> >> /usr/lib64/python2.4/_strptime.py:273(strptime)
> >> ...
>
> > actually, the C-version of strptime() is also getting called:
> >     57765    0.960    0.000   13.940    0.000 :0(strptime)
>
> > that's pretty confusing. Does the Python version call the C-version
> > (or the other way around)?
>
> The other way. The strptime function inside the time module (timemodule.c)
> just calls the strptime function written in Python (_strptime.py).
> I have no idea why it's so slow in your case.
>
> --
> Gabriel Genellina

Thanks, that helps. Still I don't understand why the native (C)
version isn't available.
Perhaps, it's broken under Windows or something.

In my test code, strptime() is called approx 60K times (5M times in
the real code)
and that takes 6 CPU secs. Thus, we get 100 usecs per call. That's
much slower
than running strptime from command line. Perhaps profiling slows
things down.

$ python -mtimeit -s 'from time import mktime, strptime'
'mktime(strptime("070501", "%y%m%d"))'
10000 loops, best of 3: 40.4 usec per loop

An easy fix in my case is to avoid strptime() altogether:
 python -mtimeit -s 'from time import mktime; s="070501"'
'mktime((int(s[0:2]), int(s[2:4]), int(s[4:6]),0,0,0,0,0,-1))'
100000 loops, best of 3: 8.6 usec per loop

Quite a bit faster.
igor
It would be nice to have access to the native version of strptime()
for performance reasons.