Boost logo

Boost :

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.


> 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;

          : timing(true), elapsed(0.0), underflow(false), overflow(false)
        basic_profiler(ident_type id)
          : id(ident_type), timing(true), elapsed(0.0), underflow(false),
        ~basic_profiler() {
          if (timing) {
        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;
        void resume() {
          timing = true;
        void pause() {
          time_elapsed tmp = t.elapsed();
          if (tmp <= t.elapsed_min()) {
            underflow = true;
          if (tmp >= t.elapsed_max()) {
            overflow = true;
          elapsed += tmp;
          timing = false;
        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?


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