|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2005-02-08 17:36:00
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.")
> - 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 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?"
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk