Peter Royal wrote:
I like your approach better, as the logic for the ProfilePoint's can be
reused.
How about renaming the current Profilable to be ProfilePoint, and then the
ProfileEnabled in your ProfiledPool above can be Profilable?
So you have a class that is Profilable, which has an
void enableProfiling( Profiler profiler )
method which registers ProfilePoints with the Profiler?
I incorporated your suggestions, with some modifications. I think that this
version is better than both my original proposal and some of the changes you
proposed.
I really want to keep the Profiler as isolated from the Profilable class as
possible. In order for it to be effective, the Profilable class must be able
to function without the existance of the Profiler, but expose the profiling
information when needed.
Using this approach, the Profiler implementation is easier at the cost of
extra objects in the system. Of course, the pool can be optimized with the
isRunning() method.
As far as the m_profiler.isRunning(), how about making Profilable have
another method
void disableProfiling()
I incorporated this idea, but renamed it to:
startProfiling();
and
stopProfiling();
This way the profiling process can be run multiple times during the life of
a system--and no bad side-effects should happen. Profiling should only
occur on active components/objects and not on ones that are initializing...
So rather than calling m_profiler.isRunning() (which would give an NPE in
your example if enableProfiling() hadn't been called :)
a Profileable object would want to keep an internal boolean indicating if
profiling had been enabled, and only update the ProfilePoint's accordingly
then.
Great idea!
Although that is neater, I think the slightly-more-complex examples above
will be more useful in the end due to the reusability of the ProfilePoint's.
-pete
Cool, then that is what is in the proposal (along with the renamed but
similarly functioning sample ProfilePoints). The only thing left is to provide
a sample....
BTW, what is the thought on the "serialize(File)" method?
The more I look at that, the less I like it. The question is, should this
be
a method directly set by a container, or should this be a configurable item?
That is my point of indecision. It would be good to get more feedback on this
though.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
