Re: [boost] Re: Boost Profiler Proposal

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-08 23:55:48

----- Original Message ----- 
From: "Rob Stewart" <stewart_at_[hidden]>
To: <boost_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Tuesday, February 08, 2005 5:36 PM
Subject: Re: [boost] Re: Boost Profiler Proposal

> From: christopher diggins <cdiggins_at_[hidden]>
>>
>> Okay, so the general consensus has been quite consistent:
>> - ability to turn off globally
>> - pause and resume
>> - As unintrusive as possible (no requirement of code reporting)
>       ^^^^^^^^^^^
> (When you get to the docs, be sure to write that as
> "nonintrusive.")

Good point.

>> - hierarchical reporting (optional)
>>
>> I think perhaps the best approach then would be a macro library. I 
>> propose
>
> That is the only way to turn it off entirely. :-(
>
>> the following macros:
>>
>> BOOST_PROFILING_OFF // turns off the macros
>>
>> BOOST_PROFILE_START(profiler_type, name)
>> BOOST_PROFILE_STOP(name)
>> BOOST_PROFILE_PAUSE(name)
>> BOOST_PROFILE_RESUME(name)
>> BOOST_PROFILE_EXPR(expression)
>> BOOST_PROFILE_REPORT(name)
>> BOOST_PROFILE_ALL(name)
>
> A better scheme would be to provide a null profiler class that
> BOOST_PROFILE_START instantiates when BOOST_PROFILE_OFF is
> defined.  Then, there can be empty, inline member functions so
> that the following code compiles away to nothing in optimized
> builds:
>
> void f()
> {
>   BOOST_PROFILER(type) prof;
>   // code to profile
>   prof.pause();
>   // code to ignore
>   prof.continue();
>   // more code to profile
> }

I like this. What if we took it a step further and wrote something like:

template<typename T1, typename T2>
struct profiler : if_<profiling_on, basic_profiler<T1, T2>, 
null_profiler>::type { };

This would entirely remove the need for macros. What do you think?

>> I then will follow Gennadiy's suggestion of multiple policies:
>>
>> basic_profiler<reporting_policy, logging_policy, collecting_policy,
>> timer_policy>
>
> In keeping with the rest, should the latter be "timing_policy?"

That would be better. Or maybe it should be just timer_t since it doesn't 
really behave like a policy.

Thanks for the comments,
Christopher