avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: New Profiler hooks
Date Wed, 12 Dec 2001 22:11:26 GMT
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

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:


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


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message