|Re: How to Profile a JET transform? [message #47167 is a reply to message #47078]
||Thu, 19 June 2008 13:36
| Paul Elder
Registered: July 2009
The 0.9.0 release of JET (due for release next week) has undergone some
performance improvements. Some notes on the experience and the outcomes:
1) I used YourKit (www.yourkit.com) as my profiling tool, but I cannot say I
did exhaustive research - it happened to be the tool at hand.
2) With it, I identified a number of key 'hot spots' in JET (which I tried
to remove). Areas of major changes were:
a) Model loading. The EMFXML parser (which translates an XML document into
EMF EObjects) is significantly slower than just using the XML DOM. As a
result, JET 0.9 includes an model loader (org.eclipse.jet.xml) which loads
XML documents via the XML DOM.
b) Writing files to the workspace can be expensive. This is not only due
to the cost of the writing, but also to consequences of it - change
listeners and builders get kicked off. Prior to JET 0.9, JET would always
write a file, even if its contents had not changed. With 0.9, JET checks for
change (by reading the existing file) prior to writing. Despite the extra
cost of reading, the net result is better in the case where many files are
c) Profiling can distorts reality. Whenever I found a hotspot, I would
test changes both with the profiler, and without (just using a stop watch).
Some things that raised a big red flag in profiling had no significant
impact on the stop watch time.
What version of JET are you using? If not 0.9, can you do a test with Ecipse
3.4, EMF 2.4 and JET 0.9?
As for tools that might help with your particular transformation, I'm less
sure. Much of the time in a transformation is spent outside of the Java
classes that represent your templates. A profiler can roll these up into
numbers for the template classes (by default, they start with _jet_). But,
that doesn't really give you much information as to what tags are
I'm all ears for suggestions on how we could make JET transforms more easily
profiled. Some ideas:
* generate tags as methods in the template class. This would make it easier
to allocate blame to individual tags. This is possible so long as the tag
contains no embedded Java code.
Powered by FUDForum
. Page generated in 0.01974 seconds