----- Original Message ----- From: "Sérgio Vale e Pace" <svpace.forum@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 11, 2005 8:48 AM Subject: Re: [boost] Re: Re: Latest version of the profiler
Hi, the library evolved a lot since your first proposal, and it seens very impressive.
Thanks.
I agree with you about do not adding new functionalities, in fact I would even remove some, I´m not particularly liked the pause/resume thing, but that´s just me.
I don't like it much neither, but it was at the top of list of requests. What concerns me is that it might lead people to think that maybe they can use the profiler to time just a few statements. This isn't a great idea because the default timer doesn't have a good enough resolution. I need to make it clear that this is intended as a quick and dirty profiler rather than a commercial tool. Another big problem with pause and resume, is that it increases error and increases the chance of underflow. Oh well, caveat user I say.
I am interested in submitting it to boost, but I have to say: I would never be able to develop it as fast as you been doing,
Not a problem, I am going to be stopping development very soon. I am just completely a final version which is satisfactory for my needs and I think those of a few others. Part of the rush, is I need it for my current library, and some of the potential users need it soon as well.
and I never made a boost submission before, but I would like to give it a try.
That is good because I don't have enough patience to do it. So do you mind taking over after my next release (probably today)? You can of course do whatever you want to the code, including simplifying the design and/or removing features.
still I do think there is need to polish and stabilize the design a little, gather some more use cases and document a fill "best pratices" before trying to submitting it
I agree.
Sérgio
Brian's suggestions have motivated me to redesign the implementation of a profiler as follows: template<typename policy_t> class basic_profiler { typedef policy_t::timer_type timer_type; typedef policy_t::duration_type duration_type; typedef policy_t::ident_type id_type; public: basic_profiler() : timing(true), elapsed(0.0), underflow(false), overflow(false) { policy_t::on_start(id); t.restart(); } basic_profiler(ident_type id) : id(ident_type), timing(true), elapsed(0.0), underflow(false), overflow(false) { policy_t::on_start(id); t.restart(); } ~basic_profiler() { if (timing) { stop(); } } void stop() { duration_type tmp = t.elapsed(); if (tmp <= t.elapsed_min()) { underflow = true; } if (tmp >= t.elapsed_max()) { overflow = true; } tmp += elapsed; elapsed = 0.0; timing = false; policy_t::on_stop(id, tmp, underflow, overflow); } void restart() { timing = true; elapsed = 0.0; policy_t::on_restart(id); timer.restart(); } void resume() { timing = true; policy_t::on_resume(id); timer.restart(); } void pause() { time_elapsed tmp = t.elapsed(); if (tmp <= t.elapsed_min()) { underflow = true; } if (tmp >= t.elapsed_max()) { overflow = true; } elapsed += tmp; timer.pause(); timing = false; policy_t::on_pause(id); } private: bool underflow; bool overflow; bool timing; ident_type id; duration_type elapsed; timer_type t; }; Now Brian can now squeeze metadata into the id. He simply has to make sure that the type can be used as a key in a map. I think this is a much more open-ended design, which anticipates things like possible bigger time durations in the policy (motivated by Gennadiy's suggestions). I'd suggest to consider looking at boost::date_time::time_duration if one wants to do this in the best possible way. That would require rewriting the timer however, yuck. Another thing about this design, is it delegates almost all of the interesting work to the policy. Which is perfect I think, because it seems there are just far too many usage scenarios to anticipate them all. Some issues which I still find lacking, are the handling of underflow / overflow conditions. Any comments or suggestions? CD.