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

Brett C. bac at OCF.Berkeley.EDU
Wed Nov 17 20:57:36 CET 2004

Nick Coghlan wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>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.
> That seems like a reasonable approach to me - one could easily make use 
> of the ticker information in a test framework. So I'll withdraw my 
> objection and give the new function a +0.

I have been mulling over this proposal and I think I am finally settling on +0 
as long as it can be shown that it does not hurt performance at all (yes, it 
shouldn't but this is the eval loop we are talking about and that thing is a 
touchy beast).

This feels like a move towards providing the same level of infor that Java's 
JMX provides (which I am not saying is good or bad; just been writing a Python 
vs. Java research paper and so I have partial Java-on-the-brain).

I think the trick is going to be making it clear in the docs that this is meant 
to give people a rough idea of where there is still a lot of Python code being 
used compared to C and not and should not be used to measure performance.


More information about the Python-Dev mailing list