Hi Harm and Marius,
I did experiement with EMF Notifications but I found it too heavy
weight and too fine grained. It's not really useful knowing when a
specific attribute is set. There's isn't enough useful context.
Ideally I would like to be able to watch *any* event that occurs as a
part of the profile. All of that useful semantic information that
comes out of each xml fragment in the trace file shouldn't be dumped
straight into the EMF model, everyone should be able to get a handle
on these events and process them however they see fit. This would mean
some sort of Event publication system and an object model representing
every possible item of an XML4Profiling trace.
Part of the problem I have with the current EMF model is that I find
it very hard to query. I can't work out how to ask the model "tell me
about all of the innovcations of method X". The model only feels
useful for traversing. But maybe that's because I don't understand all
of the code?
The concrete example I'm trying to code right now is the rule ->
Method execution time is always < 5ms.
Ideally I would like to be able to query the statistical trace model
and find out where/when the rule was violated. I don't think that's
easy right now.
To progress it becomes more efficent to evaluate these rules in real
time as trace events occur, hence wanting a handle on the trace
events. However I know such analysis places quite an overhead on the
system. Has anyone considered batching events over the wire to reduce
the network overhead?
Another part of my project involves modelling "virtual" performance of
code based on trace events that occur. For that reason I also want a
handle on the events as they come in. I can't do the analysis and
simulation I want based on the data in the EMF model
Currently I think my main gripe is the EMF model. It's completely
orienetated around the views available in the profililer. The
statistics I can collect and evaluate aren't generic. There's no way
to collect a new statistic. I can only browse the model and find out
about the statistics created and placed in the model by the trace
loader.
I've also got issues because it's hard to get a handle when a trace is
happening and grab get at the EMF model easily... Currently it's
focused on the current selection in the Profiling UI. This isn't
always useful.
I'd love to talk about this more. My University project finishes soon
(so I don't think I'm going to have written anything like what I
wanted) but I'm happy to contribute ideas and/or code.
Cheers,
Neil
On 3/12/07, Harm Sluiman <[EMAIL PROTECTED]> wrote:
Another way to look at this may be to understand what filtered data is needed
for a particular analysis. In the cases where this can be a reduction to
something manageable in memory, providing the filtering query and using the new
access layer, the right data can be provided for further analysis. That query
result can be a data source to an analysis engine and so on...
However I suspect a lot of analysis will require recursive walking etc. and a closer
binding to the data source will be needed to be perfromant where the analysis result or
at least the result of some significant data reduction would be the result of a
"query".
I would agree that live event based analysis is overkill for most use cases,
particularly since the time between events in a live cases is typically very
small.
Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,
phone:905-413-4032 fax: 4920
cell: 1-647-300-4758
mailto:[EMAIL PROTECTED]
Admin : Arlene Treanor [EMAIL PROTECTED] Tie: 969-2323 1-905-413-2323
Marius Slavescu/Toronto/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
03/12/2007 10:39 AM
Please respond to
TPTP Tracing and Profiling Tools Project developer discussions
<tptp-tracing-profiling-tools-dev@eclipse.org>
To TPTP Tracing and Profiling Tools Project developer discussions
<tptp-tracing-profiling-tools-dev@eclipse.org>
cc
Subject Re: [tptp-tracing-profiling-tools-dev] Model analysis
Hi Neil,
Watching EMF notifications could be an overkill, especially when we capture a
lot of details in the trace, also adding adapters to Trace EMF objects could
increase the footprint considerably for the in-memory case.
There are several ways to watch the trace events as they are processed,
although there is no easy way to trigger that behavior, basically if you can
override the XMLLoader you could watch the loading activity.
As I'm working on scalability and performance improvements in 4.4 I will
provide different methods of loading/persisting the monitored data (trace,
test, statistical) which will may not be based on EMF.
If you can list some of the things that you want to monitor as the event data
is processed I could probably give you more details of how you could achieve
this in a generic way so it will work with any persistence model we will use.
I'll be looking into some notification mechanism (not EMF based) and I may
provide some support in 4.4, would be good to get some of your requirements and
see what can be done in this area in 4.4.
Please open an enhancement and specify your requirements there,
Thanks !
Marius Slavescu
IBM Toronto Laboratory, Canada
Phone: 905-413-3610
"Neil Dunn" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
03/10/2007 04:29 PM
Please respond to
TPTP Tracing and Profiling Tools Project developer discussions
<tptp-tracing-profiling-tools-dev@eclipse.org>
To "TPTP Tracing and Profiling Tools Project developer discussions"
<tptp-tracing-profiling-tools-dev@eclipse.org>
cc
Subject [tptp-tracing-profiling-tools-dev] Model analysis
Hi everyone,
I'm to implement a rules engine for a profiler. The end aim is to be
able to describe you performance rules in Eclipse, exectue a profiling
session and have a report generated saying if the rules were
satisfied. A basic example is a constraint on the execution time of a
method.
It seems that the best way to do this based on what is currently
available in TPTP is to watch the EMF model and analyse it. However I
have the following problems:
* There is no uniform way to find out when a trace is occuring and
grab the current trace model. I can subscribe to ProfileEvent events
to find out when a profile is occuring but the only way I have found
to grab the corresponding trace model is use TraceUtil.getMofObject()
which returns the currently selected element in the Profiling Monitors
view. This feels like a bit of a hack
* The most appropriate time to do the analysis is as new profiling
events occur (e.g method entry, method exit) however there is no way
to hook into this. Each different type of profiling event is handled
in it's own way and I have not been able to sucessfully use the
Notification API in the EMF model for a trace to catch when events
such as method innvocations are occuring.
Guru mentioned that someone had written something similar to my idea
but specificially for memory analysis. I haven't been able to found
this in CVS, could someone point me to the correct module.
Thanks in advance for the help.
Regards,
Neil Dunn
_______________________________________________
tptp-tracing-profiling-tools-dev mailing list
tptp-tracing-profiling-tools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/tptp-tracing-profiling-tools-dev
_______________________________________________
tptp-tracing-profiling-tools-dev mailing list
tptp-tracing-profiling-tools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/tptp-tracing-profiling-tools-dev
_______________________________________________
tptp-tracing-profiling-tools-dev mailing list
tptp-tracing-profiling-tools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/tptp-tracing-profiling-tools-dev
_______________________________________________
tptp-tracing-profiling-tools-dev mailing list
tptp-tracing-profiling-tools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/tptp-tracing-profiling-tools-dev
