----- Original Message ----- From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com> To: <boost@lists.boost.org> Sent: Thursday, February 10, 2005 12:13 PM Subject: [boost] Re: Latest version of the profiler
news:004401c50f7c$779fa640$d9958242@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