Boost logo

Boost :

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-10 13:19:48

----- Original Message -----
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, February 10, 2005 12:13 PM
Subject: [boost] Re: Latest version of the profiler
> news:004401c50f7c$779fa640$d9958242_at_heronnest...
>> The latest version is at:
>> The major changes are:
>> - defining BOOST_PROFILING_OFF causes all member calls to become empty
>> statements
> Why didn't you go with MACRO-less solution?

Because it is a non-standard way of doing things. The majority of boost
libraries use macros to control compilation.

>> - basic_profiler now has three policies: logging, stats, timer
>> - profiler now supports: restart, stop, pause, resume, generate_report
>> - fixed QueryPerformanceCounter() api bug in HighResolutionTimer
> 1. Logging Policy
> This policy supposed ot be responsible for *how* you do logging (not what
> or
> when).

That seem unneccessarily inflexible. How can you determine in advance what
should be logged and when it should be logged? Also, why do you say
"supposed to"? What are the specific reasons why the logging policy design
is flawed.

I give the option to the user through the policy. I could separate the
logging policy into three separate policies: when_to_log_policy,
how_to_log_policy, what_to_log_policy. But it is to simple to warrant this
extra refactoring IMO.

> Accordingly it shoud't be event driven. It should be ... feature
> driven:
> log_start(...), log_finish(...) e.t.c. I don't really understand how you
> intend to use your current interface.

I don't see how this confusion could arise given the simplicity of the
design. Could you ask a more specific question?

> 2. Stats Policy
> Fron you docs (emphasis is mine): "The stats policy is responsible for
> collecting *and* reporting statistics". Did you notice 'and'? You still
> tring to put two eggs into same basket.

The collecting and reporting of statistics is inextricably linked. You can
only report stats that you have collected. I do not see how you could
separate the two.

> What if you want 2 different
> profilers, both scoped, but first measure wall-clock time,
> second measure
> process time?

That is beyond the scope of the library. I can not imagine a profiling tool
which would want to measure wall clock time. The profiler library measures
time durations only.

> 3. Timer concept
> I am not sure that boost::timer interface present the best abstraction for
> Timer concept.

However it is what we have to build off of. There was a lot of work that
went into it, and I am confident in the design decisions that were made. I
also like the simplicity of it.

> Amoung other things I believe you also need time_type (long,
> long long, int64_t, timeval e.t.c). Also using double for elapsed in
> general
> may not be desirable also.

I agree that this would make it more powerful, however it would also give a
false sense of security w.r.t the robustness of the tool. I don't want to
spend an inordinate amount of time dealing with the quirkiness of timers. It
is a very complex subject, and virtually impossible to do both portably and
correctly. I believe that what was good enough for boost::timer, is good
enough for boost::profiler.

>> I am still looking for a posix high-resolution timer. Hartmut suggested a
>> couple of Posix timers which he got off of Google, which unfortunately
> were
>> unusable: one was GPL'ed and the other lacked source code. Gennadiy said
>> there were some on the mailing list (I couldn't find ),
> Look here:
> Gennadiy


Christopher Diggins
Object Oriented Template Library (OOTL)

Boost list run by bdawes at, gregod at, cpdaniel at, john at