----- Original Message ----- From: "Caleb Epstein" <caleb.epstein@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 11, 2005 10:52 PM Subject: Re: [boost] Re: Re: Profiling Library suggestion
Here's a use case that I had trouble getting to work with the current profiler implementation.
I have some code that is benchmarking a relatively fast routine. I was using boost::timer and keeping track of the number of calls I could do before the timer reached some reasonable value (say 5 seconds). I then report the number of calls/sec I can make by dividing these values.
I had difficulty converting this to use the profiler code because of the small run-time of the routine. Using a timer inside my for loop just resulted in timer underflows. I think what I'm looking for is a way to bump the "count" portion of the counted_sum for a profiler without stopping it.
I have added temporarily (at http://www.cdiggins.com/profiler/v2/profiler.hpp): public: // extra functionality, may or may not stay in duration_type& recorded_elapsed() { return policy_t::stats[id].first; } int& recorded_count() { return policy_t::stats[id].second; } const duration_type& recorded_elapsed() const { return policy_t::stats[id].first; } const int& recorded_count() const { return policy_t::stats[id].second; } const duration_type& elapsed_so_far() const { return elapsed; } We can't leave the implementation of recorded_elapsed() and recorded_count() as is, because it IMO makes too many assumptions about the stats layout. I will need to find a better way to do this. This exposure of implementation details of a policy feels like a bad idea. I would prefer instead perhaps to do this: public: policy_t& get_stats_policy() { } And write a separate exposed_stats_policy, which exposes its implementation. This at least would allow implementation hiding to be a default behaviour. Any other suggestions on how to do this would be welcome. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org