RE: [boost] Re: Re: Re: Re: Latest version of the profiler

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-02-11 11:33:48

See below

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of christopher diggins
> Sent: Friday, February 11, 2005 6:51 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Re: Re: Latest version of the profiler
> 
> ----- Original Message -----
> From: "Brian Braatz" <brianb_at_[hidden]>
> > I might want to accumulate ALL of the calls, in one big honking
list.
> 
> You can already do that in a few different ways:
> 
> 1) simply naming all of the profiles the same,
> 
> 2) writing a new stats policy,
> 
> 3) write:
> 
> {
>   stats_map::iterator i = default_stats_policy::stats::begin();
>   counted_sum cs;
>   while (i != default_stats_policy::stats::end) {
>     cs += *i++;
>   }
>   cout << "total profiler entries : " << cs.first << endl;
>   cout << "total elapsed time : " << cs.second << endl;
>   cout << "average time per profile : " << cs.second / cs.first <<
endl;
> }
> 
> 4) I could simply add some features to the default_stats_policy, if
that
> is
> more appropriate.
> 
> I don't know what the best option is.
> 
> > Or
> > I might want a "overview" of the average of each profile point.
> 
> Currently also already provided in the default_stats_policy, if I
> understand
> you correctly.

[Brian Braatz] 
YES- current implementation already gives me an average of the profile
points.

> 
> > I think we need both, in addition to allowing me to put metadata
into
> > the profile point. Because with the metadata, I can now go back
through
> > the accumulated list and filter out what I care about.
> 
> I am seriously considering the metadata idea.
> 
[Brian Braatz] 
BIG GRIN :) 

> I agree with your earlier ideas that the identifier for a profile
should
> not
> be restricted to a char*.
> A problem with the current design is that a by passing a type for the
> profile idenitifer affects not just the profile, but also the stats
policy
> and the log policy. In this case of having three dependant policies, I
> would
> far prefer to have a single profile_management policy. This is not a
huge
> problem however.
> 
> Thanks for your suggestions,
> Christopher

[Brian Braatz] 
Personally- I don't think having one honker policy object is the end of
the world. In this case it is appropriate because the independent
policies are somehow implicitly "bound" by concept. If they were not, I
would argue for separate policies.

Please check out the multi-index idea post earlier by me :) 

(that may give the flexibility, with just a little extra work, to make
the profiler be "better than off the shelf". Which to me, is what Boost
libraries are about :) )