Peter Donald wrote:
Haven't looked at it closely yet but it sounds good so far. However I don't
think it has anything to do with lifecycle management and thus should
probably go into excalibur (much like Recyclable/Poolable is in
excalibur).
I might be inclined to agree with you--especially concidering to the point that
it is growing.
Just a few questions.
* Does it allow for push and pull?
ie can the component to push the profile data regardless of whether anyone is
listeneing. Can the Profiler actually pull a sample out any time it wants?
It is Pull only. The idea is to minimize the awareness of the Component being
profiled so that it _only_ provides the hooks so the Profiler can get the
information needed.
Also, as a courtesy, the Profiler tells the Component when it is running, so
the Component does not _have_ to track information when it is not necessary
(thus an optimization technique on par with the LogKit.is[Priority]Enabled).
* Most things I know about would have components with multiple points. Is
this supported? Also sometimes points are aggregations of other points - is
this supported ? Something that may be useful would be to do something like
That's the same thing Pete Royal came up with. The SEDA architecture was merely
measuring queue size and threadpool size. This is too limited for our needs.
//second parameter is the factor that the child point contribts to this point
myProfilePoint.getChildPoint( "some-string-designation", 0.01f );
In this way you could support hierarchies of points
The current version of Profilable has one method to getProfilePoints. The
ProfilePoints used in this system has an associated name. If a Profilable
happens to be a container, it can also go through it's children and gather
their profilable points.
* kinda related to above but is there a way for the container to associate
"context" information with a point. ie a Point may say it is measuring
variable X but the container may prepend this with
"myContainer.myComponentName."
Currently, not directly. A pool can easily look at it's ObjectFactory to
get the Class name of the type of object it is pooling and use that in the
ProfilePoint's name. Kind of like this:
"{classname} Pool: Max Size"
--
"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]>
