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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-13 19:42:18

----- Original Message ----- 
From: "Caleb Epstein" <caleb.epstein_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, February 12, 2005 1:09 PM
Subject: Re: [boost] Re: Re: Profiling Library suggestion

> How about this alternative.  The profiler stores its own counter which
> defaults to 1.  It implements an operator++ or a suitably named method
> (iterations? count?).  then the on_* interfaces would receive a
> counted_sum object instead of just a duration_t.

I'd prefer (if it is reasonable) to keep the profiler as simple as possible 
and delegate responsibility to the profiles whereever I can, in this case we 
would be moving counting logic from the stats_policy to the profiler. How 
about this instead:

stats_policy profiler::get_stats();

This way you can access the counting logic of your particular stats policy, 
and manipulate that however you want? Some stats policies concievably could 
have no counters. So it leaves the overall profile design more open-ended, 
but admittedly less convenient for your purposes. Would you find this 
compromise acceptable?

> Basically, I'm looking for the ability to use a single instance of a
> profiler to collect stats for number of operations each of which are
> too brief to profile on their own, but when taken in aggregate you get
> meaningful data.
>
> Does this make sense?

Actually I am a little confused, sorry. If the operation is too brief, do 
you mean it underflows? An aggregate which includes even a single underflow 
would be inaccurate, if that is what you intend to do. However, I am 
probably just confused.

> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com

Thanks
Christopher Diggins