[boost] Re: Re: Re: Re: Boost Profiler Proposal

From: Preston A. Elder (prez_at_[hidden])
Date: 2005-02-08 20:10:30

> You would write the above code as:
> 
> {
>   {
>     basic_profiler<collecting_policy> p("profile1");
>     // some code
>   }
>   // some other code we do not want to profile
>   {
>     basic_profiler<collecting_policy> p("profile1");
>     // continue profiling
>   }
>   collecting_policy::generate_report();
>   }
> }

Personally, mu biggest problem with this is thats an awful lot of
constructing and destructing.

Remember my suggestion:

Profiler p(profiler_group);

// some code
p.next("code1");

// more code
p.next("code2");

And the intervening time between the next calls (or the profiler
instantiation for that matter) would be added.  This allows for two things.

First, I could have:

Profiler big(big_group), small(small_group);
for (i=0; i<10; ++i)
{
    small.next("other");

    // some code
    small.next("code1");

    // more code
    small.next("code2");
}
big.next("my_for_loop");

allowing me to both profile individual components, of my for loop, as well
as how much the for loop as a whole is taking, and it wouldn't be a
problem.

Second, the above approach constructs big and small ONCE, and relies on no
static values, just that big_group and small_group are defined somewhere
(they may be static variables, global variables, passed into the function,
whatever).

Oh, and something I also didn't mention, the interface is DEAD simple, and
does not stop variables being defined in code block 1, and used in code
block 2.

You could also then just add a 'skip' function that would simply do the
same as next, without passing on the time to your profile group, or you
could use a value (say, "") that your profile group would ignore
(obviously, the Profile class wouldn't know its going to be ignored, but
your own profile group would).

Simplicity is the key here, there is no need to have 8 macros, or static
variables.  Plus the above approach is quite flexible without relying on
scoping syntax, and allows multiple granularity of profiling.  For
example, I could then figure out some way to disable small profiling group
but still use the big profiling group (whatever it may do, print, etc). 
Its not an 'all or nothing' approach.

-- 
PreZ :)
Founder. The Neuromancy Society (http://www.neuromancy.net)