avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@managingpartners.com>
Subject Re: New Profiler hooks
Date Wed, 12 Dec 2001 18:40:37 GMT
On Wednesday 12 December 2001 11:17 am, you wrote:
> Keep in mind the other option here:
> For a pool, the current size and max grown are the useful profiling points
> as the defined min and max are directly set in configuration.  Therefore,
> what I was thinking is this:

Thanks for the more detail explanantion :)

> class ProfiledPool implements Pool, ProfileEnabled
> {
>      ProcessedPerPeriodProfilePoint m_gets;
>      ProcessedPerPeriodProfilePoint m_puts;
>      ItemCountProfilePoint m_activeObjects;
>      ItemCountProfilePoint m_reserveObjects;
>      MaxProfilePoint m_maxRequested;
>      Profiler m_profiler;
>      List m_active;
>      List m_reserve;

I like your approach better, as the logic for the ProfilePoint's can be 

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?

> 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()

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 again, it may be simply neater to export multiple sample points:
> String[] getSampleNames();
> int[] getSamples();
> Which is not *that* much more difficult to implement in the profiler.
> The question arrizes of how to determine whether we are profiling or
> not.

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.

peter royal -> proyal@managingpartners.com

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