RE: [boost] Latest version of the profiler

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-02-10 19:26:06

> -----Original Message-----

[Brian Braatz] Wrote:
> > I for example- MIGHT take your library and stuff __FILE__ __LINE__
into
> > the id. For this I would use a macro. This is also why I made the
> > request for the char*name type to be a template param. I may want to
> > plop in my own struct that has the __FILE__ and __LINE__ in it.
> 
> The current implementation uses a map<string, pair<int, double> > for
> gathering of stats. This makes it easy to access data by profile name
and
> to
> accumulate data for a named profile. Of course this could be
rewritten,
> but
> my goal is to do as little work as possible. ;)
> 

Christopher Diggins Wrote:
> What if instead you wrote:
> 
> #define PROFILE(TKN) BOOST_PROFILE(#TKN##__FILE__##__LINE__)
> 
> Or better yet:
> 
> #ifndef BOOST_PROFILING_OFF
>   map<string, pair<int, string> > my_map;
> #endif
> 
> #ifndef BOOST_PROFILING_OFF
>   #define PROFILE(TKN) mymap[#TKN] = pair<int,string>(__LINE__,
__FILE__);
> BOOST_PROFILE(#TKN);
> #else
>   #define PROFILE(TKN) /* */
> #endif
> 
> Would these be acceptable alternatives?
> 

[Brian Braatz] 
I spent a little more time (that I really don't have today but the boost
mailing list "Draws me in..." :) ) Looking at your code at:

http://www.cdiggins.com/profiler/profiler.hpp

One thing that AT FIRST looked problematic for my usage is this:

  typedef map<string, counted_sum> stats_map;

....

struct default_stats_policy
  {
    static stats_map stats;

...

But, then I realized this is in a default Policy. So I can change that
(cool). I need to track on a per-thread basis each thread's profile
information.

Hmm... 

On the metadata issue, things I need to track
        __FILE__

I have the following needs:
        1- I have some code that is using wstring for everything else.
So the std::string seems weird here (yes I know boost is not completely
wstring compatible).
        2- I need to store BOTH the "average" for that area of code, and
also track the history of all the calls. I.e. look at the profile for
the last time we were in that function
        2- I need to be able to plug a structure of my metadata in there
somewhere. 
                - This will allow me to after the fact, scan the map and
find "sets" of profile information based on my specific stuff.
                Examples:
                        Stuff threadID in there, so "later" I can filter
out just the stuff for that thread.
                        At runtime, set a particular flag on the
metadata based on a business condition in the code.

What I would like to see in the profiler:

* An ability to give it something other than std::string for the KEY
type of the map
* An ability to track these readings in a list with my metadata

Examples:

Struct ProfileDataFileOperations
{
        string sId;
        std::string sFILE;
        int iLine;
        string sfiletouched;

        MyProfileData(string id, string file, int line,string
sFileYouTouched)
        : sId(id), sFILE(file), iLine(line),
sfiletouched(sFileYouTouched)
        {}
        Bool operator==( ProfileDataFileOperations const & other)
        {
                return sId == other.sId;
        }
}	

void savestufftofile(std::string sfile)
{
        FileOpProfiler 
        
p(ProfileDataFileOperations("savestufftofile",__FILE__,__LINE__,
                        sFile));

}

I would like to then, go back and generate a report on ALL operations
that touched a specific file.

I would also like to go back and see all the things that touched
savestufftofile

I might also want to go back and filter out based upon some other
combination of data.

The things I am describing fall into my basic issue with using
profilers. They gave you MORE information than you need, without an
easily ability to filter out or cross cut the information.

So the implementation of what I am suggesting is this:

* Make the TYPE in the map be a typedef in the policy (the template
could default to std::string)
* allow me to provide my OWN way of storing the information 
        For above, I might want to keep a big old list
        Or maybe I want what you have, but I want to plug a list<> into
the element you are using to track the profile information for a
"thing".

I am sorry if it feels like I am blowing the scope of what you are
trying to do out of the water.

I do think with some tweaks, though, you could have a profiler class
that could stand up to most of not all of the "weird" desires of folks
like me :)