(Please forgive me if this belongs on python-dev.) When measuring the performance of a Python or Python program, it is often required to keep precise count of interpreter tics and periodic checks. There is no way to to this reliably, except modify ceval.c and rebuild Python. I think facilities for performance measures should be available. It should not be neccesary edit ceval.c and rebuild Python just to measure how Python itself or a Python program performs. I am therefore proposing this change to ceval.c: New global declarations: /* tick and check counters */ volatile PY_LONG_LONG _Py_Interpreter_Ticks = 0; volatile PY_LONG_LONG _Py_Interpreter_Checks = 0; The big infinite loop in PyEval_EvalFrameEx becomes for (;;Py_Interpreter_Ticks++) { #ifdef WITH_TSC if (inst1 == 0) { with periodic checks like this: if (--_Py_Ticker < 0) { _Py_Interpreter_Checks++; The reason for this change is that _Py_Ticker cannot be used for performance measures, as the variable can be set to zero during check intervals themselves or asynchronously from callbacks/signals. The variables _Py_Interpreter_Checks and Py_Interpreter_Ticks would be available to extension developers using the declaration: extern const volatile PY_LONG_LONG _Py_Interpreter_Ticks; extern const volatile PY_LONG_LONG _Py_Interpreter_Checks; #define PyEval_GetInterpreterTicks (_Py_Interpreter_Ticks) /* or an inline function */ #define PyEval_GetInterpreterChecks (_Py_Interpreter_Checks) (A 'const volatile' is a C variable that cannot be written to, but can suddenly be changed from the environment.) From the Python side we would have: sys.tickcounter # or sys.getinterpreterticks? sys.checkcounter The counters must be 64 bit because of the speed of Python. On my computer I measure close to 3 million interpreter ticks per second. That would exhaust a (signed) 32 bit counter in 11 minutes. A signed 64 bit counter could go on for 24 thousand years. (This is not covered by Guido's moratorium as it is an implementation and library issue.) Regards, Sturla Molden