Peter Royal wrote:
On Wednesday 12 December 2001 10:26 am, you wrote:
Purposeful Design Constraints
1) Profilable only provides a simple integer sample.
Why is that a purposeful constraint? That constraint is directly responsible
for your issue #1, multiple points per component. I think issue #1 is huge
because for a pool you many want to know current size, defined max & min, max
it has ever grown to, etc. I think multiple points/component would be the
norm, rather than the excepetion.
How about changing Profilable to
interface Profilable
{
/**
* A list of the sample points that this component exposes.
*/
String[] getSamplePoints();
/**
* Obtain the sample. All samples are an integer, so the profiled objects
* must measure quantity (numbers of items), rate (items/period), time in
* milliseconds, etc.
*/
int getSample(String point);
}
Otherwise I think the proposal looks good! :)
-pete
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:
A pool defines a series of objects like this:
class MaxProfilePoint implements Profilable
{
int m_max = 0;
void setActive( int currentActive )
{
if ( m_max < currentActive )
{
m_max = currentActive;
}
}
int getSample()
{
return m_max;
}
}
class ItemCountProfilePoint implements Profilable
{
int m_current = 0;
void setActive( int currentActive )
{
m_current = currentActive;
}
int getSample()
{
return m_current;
}
}
class ProcessedPerPeriodProfilePoint implements Profilable
{
int m_current = 0;
void increment()
{
m_current++;
}
int getSample()
{
return m_current;
m_current = 0;
}
}
If the profiler was passed to the Pool implementation, then the
specific profile objects would be passed to the Profiler. Kind
of like this:
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;
Poolable get()
{
if (m_profiler.isRunning())
{
m_gets.increment();
}
m_active.add(m_reserve.remove(0));
if (m_profiler.isRunning())
{
m_maxRequested.setActive(m_active.size());
m_activeObjects.setActive(m_active.size());
m_reserveObjects;.setActive(m_reserve.size());
}
}
void put( Poolable obj )
{
if (m_profiler.isRunning())
{
m_puts.increment();
}
m_active.remove( obj );
m_reserve.add( obj );
if (m_profiler.isRunning())
{
m_activeObjects.setActive(m_active.size());
m_reserveObjects;.setActive(m_reserve.size());
}
}
void enableProfiling( Profiler profiler )
{
profiler.add( "Pool: number of gets/sample", m_gets );
profiler.add( "Pool: number of puts/sample", m_puts );
profiler.add( "Pool: max concurrent active objects", m_maxRequested);
profiler.add( "Pool: current number of reserve objects",
m_reserveObjects);
profiler.add( "Pool: current number of active objects",
m_activeObjects);
m_profiler = 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.
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.
--
"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]>
