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).
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?
* 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
//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
* 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."
On Thu, 13 Dec 2001 02:26, Berin Loritsch wrote:
> I added a couple of interfaces in the Framework proposal directory that I
> think could be good for debugging and performance monitoring a running
> system.
>
> The new folder is ${framework}/src/proposal/profile
>
> The two new interfaces are Profiler and Profilable. The concept (lifted
> from SEDA) is that all profiling points are integers. For instance the
> types of samples that are taken in a profiling tool are number calls on
> methods (integer results determining coverage), number of milliseconds each
> method takes (integer results determining hotspots), etc.
>
> While it is impractical to determine the traditional Profiling points in a
> running system without modifying the JVM or proxying _everything_, there
> are a number of other profiling points that truly make sense. For
> instance, Number of Active Threads in a Pool, Max Poolable items, Items
> processed per sample, etc.
>
> The concept is simple, and observes IoC in the following manner:
>
> 1) The Profiler is designed to live inside the Container. It is the
> Container's job to register the Profilable elements with the Profiler. The
> Profiler is in control of how often samples are taken, and how the
> information is serialized to the destination file. It is the Container's
> responsibility to determine where that file should be located.
>
> 2) The Profilable objects are designed to return very simple profiling
> points.
>
>
> Possible Issues:
>
> 1) An Component may want to expose multiple profiling points. In this
> case, the profiler would have to be passed to the object that registers
> specialized Profilable objects. We would need a third interface to pass
> the Profiler to the Components.
>
> 2) We might decide that it is a configurable item for the destination of
> the profiling results, so the serialize(File) method might be removed.
>
> 3) We might not want to expose the isRunning() method to all the Components
> in this case.
>
> Purposeful Design Constraints
>
> 1) Profilable only provides a simple integer sample.
>
> 2) The existance of the Profiler must be optional.
>
> 3) The Profiler must be able to be added and removed from a system without
> restarting it.
>
> 4) The Profiling should be done asynchronously so as not to interfere with
> the critical path. That is why the Profiler polls the Profilable
> objects instead of the Profilable objects posting changes.
>
> Let me know what you think.
>
> I believe that Profilable is a core concern area since we want to enable
> the exposing of the internal state in a controlled manner. We want to be
> able to profile object state so we know where excessive work is being
> performed. I also think that a useful Profiler would be better created in
> Excalibur, so there is a dicotomy. The interface should be in Framework so
> that people know how to design their containers to work with a Profiler.
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
