RE: [boost] Re: Profiling Library suggestion

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Friday, February 04, 2005 2:45 PM To: boost@lists.boost.org Subject: [boost] Re: Profiling Library suggestion
christopher diggins wrote:
I was searching around boost for mention of a profiling library. A fellow by the name of Carl Daniels posted something about an invasive profiling library. I was wondering in anyone knows what happened to that project? Profiling seems lacking at Boost, is anyone else interested in such a thing?
Would a trivial policy driven RAII type be sufficient to garner interest as a mini-library?
e.g.
struct ProfilerDefaultPolicy { OnElapsed(int msec) { cout << "time elapsed (msec): " << msec << endl; } };
template<typename Policy_T = ProfilerDefaultPolicy> class Profiler { public: Profiler() { mnStart = GetTickCount(); }; ~Profiler() { Policy_T::OnElapsed(GetMSecElapsed()); }; int GetMSecElapsed() { return GetTickCount() - mnStart; }; int GetTickCount() { return int(double(clock()) * 1000 / CLOCKS_PER_SEC); }; private: int mnStart; };
usage:
void MyRoutine() { Profiler<> p; // do stuff }
[Jonathan Turkanis]:
How about:
typedef profiled< MyClass, Interface, Profiler<> > > MyProfiledClass;
?
[Brian Braatz] That is a good idea (use a AOP style weave). It begs asking here- when we talk about profiling, what are the use cases you guys see. I have some stuff to implement profiling on in the coming weeks. My situations are as follows: * Profile and log the profiling results of my unit tests between the checkpoints -> Either explicitly or I may redefine BOOST_CHECKPOINT * Profile an application for when makes certain method calls on some COM objects- Also log this information. -> Problem is, folks have coded directly to the COM objects proxy class. Because of this, the AOP style typedef trick will not work unless I push the proxy classes into a namespace- and redefine them in the global namespace with a weave in place. (structurally this might be more work than I want to deal with) * profiling specific operations which cross cut many areas of the system and only doing that when certain dynamic conditions exist I am asking you guys for how you need to use profiling because by talking aobut the problem that is to be solved, it might make the discussion of what the solution is easier to address.

----- Original Message ----- From: "Brian Braatz" <brianb@rmtg.com> To: <boost@lists.boost.org> Sent: Friday, February 04, 2005 8:05 PM Subject: RE: [boost] Re: Profiling Library suggestion
[Brian Braatz] That is a good idea (use a AOP style weave).
It begs asking here- when we talk about profiling, what are the use cases you guys see.
I have some stuff to implement profiling on in the coming weeks. My situations are as follows:
* Profile and log the profiling results of my unit tests between the checkpoints -> Either explicitly or I may redefine BOOST_CHECKPOINT
The profiler that I am proposing would only measure a code block. This restriction is not too burdensome for my purposes, but I can not speak as to other people's unit tests. What is your view on this, generally and w.r.t to your current specific usage case?
* Profile an application for when makes certain method calls on some COM objects- Also log this information. -> Problem is, folks have coded directly to the COM objects proxy class. Because of this, the AOP style typedef trick will not work unless I push the proxy classes into a namespace- and redefine them in the global namespace with a weave in place. (structurally this might be more work than I want to deal with)
* profiling specific operations which cross cut many areas of the system and only doing that when certain dynamic conditions exist
This can be done I believe with a customized profiler policy.
I am asking you guys for how you need to use profiling because by talking aobut the problem that is to be solved, it might make the discussion of what the solution is easier to address.
Thanks for bringing these use cases to our attention. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

The profiler that I am proposing would only measure a code block. This restriction is not too burdensome for my purposes, but I can not speak as to other people's unit tests. What is your view on this, generally and w.r.t to your current specific usage case?
Well, profiling associated to a block covers most case but definitively not all cases. So for other cases, we need to be able to start or stop the profiler for a given counter. Cases where blocks profiling are not enough include : - Removing time elapsed in the user interface (say we display a message box to the user). - Profiling that should start in one function and end in another one. - We might need to stop accumulating before the end of the scope in some cases (for example, before displaying an error to the user). - Some timing might be related to event handling or idle processing. - We might want to deduce the time from an inner block to see the calling overhead. For most flexibility, we need automatic (RAII) and manual profiling (explicit start and stop and increment). Philippe

----- Original Message ----- From: "Philippe Mori" <philippe_mori@hotmail.com> To: <boost@lists.boost.org> Sent: Saturday, February 05, 2005 7:01 PM Subject: [boost] Re: Re: Profiling Library suggestion
Well, profiling associated to a block covers most case but definitively not all cases. So for other cases, we need to be able to start or stop the profiler for a given counter.
Cases where blocks profiling are not enough include :
- Removing time elapsed in the user interface (say we display a message box to the user). - Profiling that should start in one function and end in another one. - We might need to stop accumulating before the end of the scope in some cases (for example, before displaying an error to the user). - Some timing might be related to event handling or idle processing. - We might want to deduce the time from an inner block to see the calling overhead.
For most flexibility, we need automatic (RAII) and manual profiling (explicit start and stop and increment).
Good points. In your opinion would introducing: stop() continue() restart() member functions be sufficient? CD

On Sat, 5 Feb 2005 19:01:01 -0500, Philippe Mori <philippe_mori@hotmail.com> wrote: <snip> sorry for the delay but do you mind elaborating these 3 points
Cases where blocks profiling are not enough include : <snip> - We might need to stop accumulating before the end of the scope in some cases (for example, before displaying an error to the user). - Some timing might be related to event handling or idle processing. - We might want to deduce the time from an inner block to see the calling overhead. Thank´s Sérgio
participants (4)
-
Brian Braatz
-
christopher diggins
-
Philippe Mori
-
Sérgio Vale e Pace