$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Boost.tracer] library request
From: Kenny Riddile (kfriddile_at_[hidden])
Date: 2010-01-20 12:53:26
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://listarchives.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.