RetroSearch Browse

Mon Nov 15 21:28:19 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/049930.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/049930.html below:

[Python-Dev] proposal+patch: sys.gettickeraccumulation()