Andrew Chinkoff wrote:
[Boost.tracer] library request is founded on a desire to trace some statistics about program execution.
The sample program below demonstrates these statistics.
Sample program file:
******** START OF FILE ******** #include <tracer.h> void foo() { TRACE_LIFETIME; usleep(rand() % 100000); } int main() { TRACE_LIFETIME; for(int i = 0; i < 100; ++i) foo(); } ******** END OF FILE ********
Produced log file:
******** START OF FILE ******** All the program time: 05265686 us (micro secs)
TRACE POINT: Function: int main() Calls: 0000000001 times Average T between calls: 0000000000 us Average life T: 0005264459 us File: main.cpp Line: 00000009
TRACE POINT: Function: void foo() Calls: 0000000100 times Average T between calls: 0000051665 us Average life T: 0000052606 us File: main.cpp Line: 00000004 ******** END OF FILE ********
Comment:
TRACE_LIFETIME is a MACRO that traces some scope statistics, namely: "Function" - the function name where the scope is; "Calls" - number of entries into this scope; "Average T between calls" - average time period between "Calls"; "Average life T" - average time spent in this scope.
Conclusion:
I think it is reasonable to introduce this trace functionality into (for example) boost::tracer namespace. I had wrote tracer.h and tracer.cpp source files and I wish Boost community to consider them.
Thank You. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've used simpler implementations of things like this before and always had an issue with nested trace points (usually nested function calls where each function contains a trace point). When the nesting is deep enough, the cumulative overhead of all the tracing functionality made the data unreliable except for the inner-most trace points. It would be interesting to know which of Boost.Chrono, Boost.Tracer, and Boost.Log handle this the best.