RE: [boost] Re: Re: Re: Re: Latest version of the profiler
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of christopher diggins
----- Original Message ----- From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
1. Profiler type 1 Log clock units and report mks into ostream 2. Profiler type 2 Log system/user time anf reports into Boost.Test log
Both profiler I want to be able to use as scoped or accumulating.
Gennadiy
Can you please be more specific. I don't understand what you want and precisely what the problem is. I am pretty sure we have different ideas of what a "report" is and what it means to "log".
1. Profiler type 1 Collect clock units and report mks into ostream 2. Profiler type 2 Collect system/user time anf reports into Boost.Test log
Both profiler I want to be able to use as scoped or accumulating.
Gennadiy
Christopher Diggins Wrote:
Gennadiy,
Your post makes almost as little sense as before, simply changing "Log" to "Collect" doesn't help me out much. What you wrote is virtually incomprehensible! It seems to me that you aren't really making an effort to help me out here.
What does "report mks into ostream" mean? When do you want to do these reports? What do you want reported. As far as I can tell you can do
with my code. Why do you think you can't? How and when do you want to "collect system/user time"? Why would you want to log it? How would you report it? And why can't you do this with the current library? Is "anf" some kind of acronym?
If you don't want to take the time to respond to my questions carefully, and respectfully than I would ask that you simply don't respond. I am at
[Brian Braatz] Yes- those are the words I was trying to say. I might want to accumulate ALL of the calls, in one big honking list. Or I might want a "overview" of the average of each profile point. 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. ** this is the big piece that is missing for me from off the shelf profilers ** this the
limit of my patience with your negative attitude and lack of courtesy.
[Brian Braatz] Part of the problem with all communication is we all have buzzwords and different ways of phrasing concepts. I know I for one, have a HARD TIME getting an idea typed out (as you will see in my previous post :) ). I cannot speak for Gennadiy, but I believe he was just trying to share his thoughts and I do not think you should get offended. This list is a pretty big thing and we are bound to run into situations where a few lines of text make sense to some but not others. The funny thing, is I saw his post and went "YES! That is what I was trying to say!". Which is a different reaction than you had. Brian
On Thu, 10 Feb 2005 17:33:19 -0700, Brian Braatz <brianb@rmtg.com> wrote:
Yes- those are the words I was trying to say.
I might want to accumulate ALL of the calls, in one big honking list. Or I might want a "overview" of the average of each profile point.
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.
** this is the big piece that is missing for me from off the shelf profilers **
smells like mixins to me. something like this would be apropriate (pseudo code)? { profiler< log_all< log_overview<> > > prof; // profiled code } Sérgio
----- Original Message ----- From: "Brian Braatz" <brianb@rmtg.com>
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.
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. 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
participants (3)
-
Brian Braatz -
christopher diggins -
Sérgio Vale e Pace