Re: [boost] Re: Latest version of the profiler

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: http://www.cdiggins.com/profiler
>>
>> 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:
>
> http://lists.boost.org/MailArchives/boost/msg47483.php
> http://lists.boost.org/MailArchives/boost-users/msg08974.php
> http://lists.boost.org/MailArchives/boost/msg64458.php
>
> Gennadiy

Thanks,

Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org