CPU vs Wall time Profiling
Hi all, Is there a reason behind the fact that the Python profilers work with Wall time by default? There are OS-dependent ways to get the CPU time of a thread, and giving that choice to the user _somehow_ ( to use wall vs cpu time) might be a good feature? -- Sumer Cip
On Tue, Feb 21, 2012 at 2:00 PM, Sümer Cip <sumerc@gmail.com> wrote:
Hi all,
Is there a reason behind the fact that the Python profilers work with Wall time by default? There are OS-dependent ways to get the CPU time of a thread, and giving that choice to the user _somehow_ ( to use wall vs cpu time) might be a good feature?
What would you use for linux for example? Cheers, fijal
Python 3.3 has two new functions in the time module: monotonic() and wallclock(). Victor
On Tue, Feb 21, 2012 at 1:00 PM, Sümer Cip <sumerc@gmail.com> wrote:
Is there a reason behind the fact that the Python profilers work with Wall time by default? There are OS-dependent ways to get the CPU time of a thread, and giving that choice to the user _somehow_ ( to use wall vs cpu time) might be a good feature?
The original reason was that the Unix wall clock was more accurate than its CPU clock. If that's changed we should probably (perhaps in a platform-dependent way) change the default to the most accurate clock available. -- --Guido van Rossum (python.org/~guido)
The original reason was that the Unix wall clock was more accurate than its CPU clock. If that's changed we should probably (perhaps in a platform-dependent way) change the default to the most accurate clock available.
Currently it seems clock_gettime() APIs have nanosecond resolution and OTOH gettimeofday() have microsecond. Other than that, clock_gettime() has a significant advantage: it has per-process timer available which will increase the accuracy of the timing information of the profiled application. -- Sumer Cip
participants (4)
-
Guido van Rossum -
Maciej Fijalkowski -
Sümer Cip -
Victor Stinner