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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-11 10:54:58

----- Original Message ----- 
From: "Sérgio Vale e Pace" <svpace.forum_at_[hidden]>
To: <boost_at_[hidden]>
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.