[PEAK] PROPOSAL: Performance tracking service for PEAK

[Phillip J. Eby]

At 01:31 PM 12/19/03 +1000, Uwe (Peter) Feldtmann wrote:
>Would you consider adding pause() and pause_all() methods?

stop() is a pause, if you use resume() to continue.  I'm not sure I see 
what a stop_all() would do.


>These would enable timers to be used in say a time logging app where the 
>user is working on one area with a timer running and is interrupted by 
>another task that needs to be timed independantly and exclusively.

Well, that's an interesting use case, but it doesn't seem like this service 
would actually be of much help for that.  First off, timer keys are dotted 
hierarchicals, like property names.  Second, an app such as you describe 
would only care about elapsed time, not CPU time.  Third, an app like that 
would want to be able to display the timers in progress, which means it 
would need to be able to get intermediate measurements.  This service is 
specifically designed so there is *no way* to get intermediate 
measurements, so that measurements only need to be taken if there are 
listeners registered.  This is so that you can safely sprinkle timer calls 
all over an application without it affecting performance much when you're 
not actually measuring it.

In short, I don't really think you want to try to use this service for a 
purpose such as you described.  You'd probably be better off with an 
interface designed specifically for what you're trying to accomplish.