Re: [boost] Re: Re: Profiling Library suggestion

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-12 10:25:30

----- Original Message ----- 
From: "Caleb Epstein" <caleb.epstein_at_[hidden]>
To: <boost_at_[hidden]>
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