Metadata for boost boost.signal and profiling library :was [RE: [boost] Re: Profiling Library suggestion

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

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto: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: http://www.boost.org/libs/timer/timer.htm
and I
> would humbly submit that perhaps what is lacking in progress_timer is
a
> policy, and the ability to name profiles. I would like then to
propose:
> 
>   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
may
> modify the behaviour of the profiler, without rewriting the class. It
can
> also be used with more high-performance timers if the user has one at
> their
> disposal.
> 
> Any comments or suggestions?
> 
> Christopher Diggins

[Brian Braatz] 

Christopher,
        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
strings.
        
        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.