|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk