[Python-Dev] proposal+patch: sys.gettickeraccumulation()
Ralf W. Grosse-Kunstleve
rwgk at cci.lbl.gov
Mon Nov 15 21:28:19 CET 2004
Nick Coghlan wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > >Knowing "I'm spending x% of the time executing Python code" just isn't
> > >really all that interesting,
> >
> > Right. Sorry if I gave the wrong impression that this could be
> > interesting. It is indeed not. What is interesting is the estimated
> > benefit of reimplementing a piece of Python in C/C++. This is in
> > fact highly correlated with the time/tick.
>
> Ah, OK, I think I better understand what you're trying to achieve now.
> Does knowing that the 2.4 profiler splits out C invocations from the
> calling Python methods make a difference here?
Yes, this is a very helpful improvement. Thanks for pointing this
out! It gives us a more direct way of pin-pointing the time sinks.
However, I see time.time()/sys.gettickeraccumulation() as a
complementary source of information:
profiler:
factor 8 runtime penalty
very detailed information
time.time()/sys.gettickeraccumulation():
no runtime penalty
global information
As we work on new algorithms we can easily monitor the time/tick
without a runtime penalty. As long as the ratio stays reasonably high
(e.g. because we use numarray-like array operations already coded in
C++) we don't have to do anything. If the ratio goes down significantly
we can run the profiler to do detailed analysis of the new code.
Cheers,
Ralf
More information about the Python-Dev
mailing list