(My SMTP server is cracking up)
-------- Original Message -------- Subject: Re: New AltProfile package Date: Fri, 08 Mar 2002 09:20:33 -0500 From: Berin Loritsch <[EMAIL PROTECTED]> To: Avalon Developers List <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Leif Mortenson wrote: > > >>> 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 > setProfilerManager > method. > > 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. Let's keep it in scratchpad just a little while longer, there are a couple things to straighten out first. Once we have a GUI that can attach itself to an external JVM we can consider the move to the main package. The memory profilepoints should be default and part of the ProfileManager, and not ProfileableComponentManager. The PCM (when integrated with the ECM) should worry about the ComponentHandlers and other metadata that is specific to mananging components. >>> 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. :-) I'll see what I can do. I promised the JMeter folks that I would take a look at the entries in BugZilla this weekend for the SSL bugs they are experiencing. >> 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. Looking at the two code snippets, the second one is the only one that would work in a multithreaded environment. (Unless you had a separate ProfilePoint per thread which would not be optimal). > lookup() > { > long start = System.currentTimeMillis(); > // Do stuff > if ( m_lookupLengthProfilePoint.isActive() ) > { > m_lookupLengthProfilePoint.setValue( > (int)(System.currentTimeMillis() - start) ); > } > } > > This way will be a little faster when the profiler is disabled. True. I agree that this type of profiling is not entirely accurate, but this harness also allows us to inspect where time is being spent in a system. It does enable us to have a new implementation of JMeter that is more elegant.... I tried to talk to the JMeter folks about providing the GUI for our profiling package. It turns out that there are only a few folks working on that project, and they really don't have the resources to overhaul their code to support our profiling package :(. However, I will say that I *really* like the meters you have in altprofile! I discovered that if I click on the line, I can see the average mean of the profile samples superimposed on the actuals. That kicks butt! BTW, would it be too difficult to add a Std. Deviation marking? Since Standard deviations are over a long aggregation of samples, it can be placed to the side of the graph. Usually the marks look like this: --+-- (Max) | * (Average Mean) | | | --+-- (Min) That way we can see that if results are not average, which side of the equation they lay on. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- "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]>
