[boost] Re: Boost Profiler Proposal

From: Bob Bell (belvis_at_[hidden])
Date: 2005-02-08 14:14:34

christopher diggins <cdiggins <at> videotron.ca> writes:
> ----- Original Message ----- 
> From: "Gennadiy Rozental" <gennadiy.rozental <at> thomson.com>
> >> > 3. Frequently code you want to profile is "interrupted" with islands of
> >> > code
> >> > that you are not interested in. You need an ability to do accumulation
> >>
> >> I would prefer to leave this to the user when they generate their report.
> > I
> >> see no real obstacle for them to do the subtraction of stats.
> >
> > I don't know what substraction you mean. It's rather addition.
> 
> There are two ways to compute an island:
> 
> Version 1)
> Subtraction method:
> 
> {
>   profile p1("name1")
>   {
>     profile p2("name2");
>     // island
>   }
> }
> cout << collecting_policy["name1"].first - collecting_policy["name2"].first 
> << endl;
> 

One problem with this approach is that p1 measures the time it takes to
construct and destruct p2, which adds noise to the final result.

> Version 2)
> Addition method:
> 
> {
>   profile p1("name1");
> }
> // island
> {
>   profiler p2("name2");
> }
> 
> cout << collecting_policy["name1"].first + collecting_policy["name2"].first 
> << endl;
> 
> Version 3)
> Shared Named method :
> 
> {
>   profile p1("name1");
> }
> // island
> {
>   profiler p1("name1");
> }
> 
> cout << collecting_policy["name1"].first;

A general problem is that these approaches seem to require more restructuring
of the code; it seems unrealistic that the islands you want to ignore and the
code you want to time will be so neatly separated into different blocks, so
the programmer will have to do a bit of editing to move the code around until
it's timing what he wants to time. Further, at some point I will want to
remove the profiling code for release, either by turning it off (leaving my
source code as is, with all of the profiling instrumentation in place), or by
editing the code to remove the profiling.

These points argue for making the profiling system as unintrusive as possible.
The more editing I have to do in order to time my code, the more cumbersome
the profiler is to use. Also, the more I have to edit the code, the more I
risk introducing errors.

Pause/resume functionality is much less intrusive. I can leave out islands of
code using only pure additions to my source code; no rearrangements are
necessary.

A further point in support of pause/resume functions is that every profiling
library I've ever used provides them; why demand the user learn a new way of
doing things when existing practice already works?

A final data point is an answer to your original question "Would you use it?"
Not without being able to pause and resume the profiler. I also wouldn't be
interested in it as long as the reporting and collection concepts are confused.

Bob