avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <l...@silveregg.co.jp>
Subject Re: New AltProfile package
Date Fri, 08 Mar 2002 02:42:15 GMT

Berin Loritsch wrote:

>> I was actually already giving this some thought.  Is there something 
>> that can be done in parallel with
>> the work in Phoenix with JMX?  I am just getting my feet wet with 
>> that stuff.  Doing the necessary
>> abstractions to allow the ProfilerManager to be used via RMI is not 
>> very difficult.
> Check out AltRMI, it is a quicker implementation, and is an Apache
> project (in Jakarta Commons).  We are using it in Avalon Apps. 

Ok, I'll get on that.

>> What would you think of going ahead and changing the package name to 
>> something more
>> permanent.  I would like to start seeing more people use this so that 
>> more of the usage issues
>> can be worked out.   You had mentioned that you would like to change 
>> the name from
>> Profiler to Instrumentor.  Shall I go ahead and do that by creating a 
>> new instrument package?
> Yes.  I would also go ahead and remove the profile package and
> altprofile package, so we can focus all effort on the instrument
> package.  This package, IMO, makes Excalibur suddenly really
> popular.  If we can get this finalized by the time I get to covering
> Excalibur in my book (sometime after May) I can cover it. 

Where should I create it?  In the scratchpad or java tree.  Placing it 
into the java tree, while on
one hand could be considered early, would also allow it to be more 
integrated with the ECM.
I can do the same thing with the PCM (ICM) but it would require a lot of 
duplication of code
especially with the handlers.  The way I would integrate it with the ECM 
would be to have the
ECM work exactly as it does now unless a ProfilerManager was set via the 

Basicly, the ProfilerManageable interface would have as its contract 
that implementing classes
would need to be able to function whether the setProfilerManager method 
was called or not.
But that the method would only be called during the object's 
initialization phase.

>> So far it is just a search and replace problem.  It will get more 
>> complicated later the more
>> people begin to play with it.
> Exactly.
> The reason I wanted the PCM to record lookup/release cycles is because
> I want to run a modified version of the ContainerProfile class to see
> where the slowdown is.  I want to instrument ContainerManager as well
> so that we can see what is going on.  Right now I am seeing 113:1
> performance difference.  If I extend the default timeout for the Command
> Manager, the gap narrows.  However, I do not see appreciable activity
> on the CPU to check events every 1/10 of a second--which is what gives
> the CommandManager the ability to rock. 

I need to get in and look at this still :-)  Can I talk you into 
creating a new
example in the examples directory for it?  It makes it a lot easier to 
get into
the new packages having an example. :-)

> How difficult is it to measure average timing of a method with the
> altprofile package?
> lookup()
> {
>     m_lookupLengthProfilePoint.start();
>     // .... Do stuff
>    m_lookupLengthProfilePoint.stop();
> }
> lookup()
> {
>    long start = System.currentTimeMillis();
>    // .... Do stuff
>    m_lookupLengthProfilePoint.setValue( System.currentTimeMillis() -
>                                          start );
> } 

Right now you would use the second method.  The thing to be careful with 
this kind of profiling
though is that the resolution of System.currentTimeMillis is not all 
that great.  So it really
depends what the "Do stuff" is and how long it will take.  If it is too 
short, you will get lots of
0 length durations.  Windows seems to have poor resolution.  I get a lot 
of 0, 10, 40 numbers
when I do this kind of profiling.

    long start = System.currentTimeMillis();
    // Do stuff
    if ( m_lookupLengthProfilePoint.isActive() )
(int)(System.currentTimeMillis() - start) );

This way will be a little faster when the profiler is disabled.


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