Boost logo

Boost :

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-02-04 16:31:45

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of christopher diggins
> > How is it better than what boost::timer provide?
> >
> > Gennadiy
> Hello,
> I was unaware of timer's existance, thanks for pointing it out. I had
> searched for "profiling", and "profiler".
> So I just took a look at:
and I
> would humbly submit that perhaps what is lacking in progress_timer is
> policy, and the ability to name profiles. I would like then to
> struct profiler_default_policy {
> typedef boost::timer timer_t;
> static void on_profiled(const char* name, const timer_t& t) {
> double sec = t.elapsed();
> cout << "time elapsed (msec) during profile " << name << " was "
> sec / 1000;
> if (sec <= t.elapsed_min()) {
> cout << " *underflow* ";
> }
> if (sec >= t.elapsed_max())
> cout << " *overflow* ";
> }
> cout << endl;
> }
> };
> struct interesting_profiler_policy {
> typedef boost::timer timer_t;
> static map<string, double> profiles;
> static void on_profiled(const char* name, const timer_t& t) {
> double sec = t.elapsed();
> profiles[name] = sec;
> }
> };
> template<typename policy_t>
> class basic_profiler {
> public:
> profiler(char const* s = "") : name(s) { };
> ~profiler() { policy_t::on_profiled(name, timer); };
> private:
> char const* name;
> typename policy_t::timer_t timer;
> };
> typedef basic_profiler<default_profiler_policy> profiler;
> This would have an advantage over progress_timer that library users
> modify the behaviour of the profiler, without rewriting the class. It
> also be used with more high-performance timers if the user has one at
> their
> disposal.
> Any comments or suggestions?
> Christopher Diggins

[Brian Braatz]

        I like this idea and thank you for writing that up.

I haven't had the time to write it up, but I was going to make a similar
request of boost.signals.

        The main reason for this, I built something on top of
boost.signal and it uses a lot of signals\slots, it can be difficult to
runtime debug due to not having the ability to query the signal for
dumping all that meta-data out. (i.e. give me the debug strings for each
slot)- what I do instead is keep a separate vector of those debug
        This seems to be a similar issue to the profiling metadata
suggestion that you have written up.

        My question to this list:

* What do you guys think of Christopher's Suggestion in general for
supporting extra metadata for profiling? Boost.Signal?
        With some libraries some it is easily possible (hahaha
boost.variant) for me, I have not figured out how to cleanly do it to a
slot yet :)
                (though honestly I have not had the time to further
analyze how that lib works internally) (<< disclaimer in case I missed
something dirt simple)

Converse argument would be:

Put your profiler in a named collection. That might work for profiler
(sorry I am not familiar with that lib to know if it supports copy or
what the implications of copying one are).

For signal- In a few hours of analysis I don't see how to do it yet.

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