Re: [boost] [Boost.tracer] library request

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://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.