-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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.