Home » Archived » M2M (model-to-model transformation) » [QVTO] Any way to speed up transformation?(Transformation takes too much time, unacceptable for user experience)
|
Re: [QVTO] Any way to speed up transformation? [message #737023 is a reply to message #736985] |
Fri, 14 October 2011 15:28 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Ed Willink![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=ed%40willink.me.uk) Messages: 7681 Registered: July 2009 |
Senior Member |
|
|
Hi
I'm not an expert on the way QVTo works, but have observed some of its
operation.
Unless you have some strange outer loop, I would certainly expect that
all the parsing and analysis would occur before execution starts, or
just possibly lazily on the first encounter. Observing when and what
Resources are created can be very instructive.
The QVTo engine extends the OCL evaluator and so gives an interpreted
execution. I don't think that there is a great deal of
compilation/optimisation as such.
The almost declarative nature of QVTo makes it quite easy to
accidentally do things repeatedly; it is worth understanding what is
happening and perhaps caching some results in let variables or Dicts. I
find the resolve capability very confusing and usually indaequate and
always maintain my own in2out Dict. This might help you. If you have
many rules, you may be performing long is-it-A, is-it-B, is-it-C match
searches. You may be able to structure these to help the naive
interpreted execution.
The QVTo engine maintains an EMF resource internally, so in principle it
should be possible to serialize this after parsing and analysis and
reuse it later. However beware that such a serialisation is necessarily
a proprietary format since the OMG specification is incomplete and the
related Eclipse tooling is Ecore rather than EMOF-based.
[The OCL tooling will support generation of Java in the Juno release
giving one to two orders of magnitude speed improvement, however it is
not clear when or if QVTo will be able to exploit this.]
Regards
Ed Willink
On 14/10/2011 15:41, Vitaly Savickas wrote:
> Hi,
>
> I am using QVTO transformation to generate something out of a diagram
> in a custom editor. The QVTO syntax and semantics suit great for the
> purpose, but the transformation takes too much time for some reason.
> Even for the simplest diagram with a few elements. My (only a) guess
> is that it happens because I have a lot of scripts and they have many
> rules. I don't know how QVTO engine works, but I assume it compiles
> them at each run time, so that can be a slowdown. Is there a way to
> speed it up, maybe by precompiling the scripts once and for all as
> they don't change anyway?
>
> Regards,
> Vitaly
|
|
| | | |
Re: [QVTO] Any way to speed up transformation? [message #737687 is a reply to message #737265] |
Sat, 15 October 2011 09:58 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Ed Willink![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=ed%40willink.me.uk) Messages: 7681 Registered: July 2009 |
Senior Member |
|
|
Hi
I initially wrote "EMF resource" then I wrote "XMIResourceImpl" which is
one of the classes that should not be constructed very often; once for
each file/model loaded. You may find about 20 Resources get created for
detailed XMI and OCL requirements, but no Resource should get loaded
more than twice, preferably not more than once.
Other classes that shouldn't be constructed often are ResourceSetImpl
(at most five) and OCLAnalyzer (possibly one per parse, ideally reused).
Instrumenting the major actions of these with just a System.println of
System.currentMilliseconds may provide a more useful indication of where
the time goes than the vast detail that VisualVM can provide.
Regards
Ed Willink
On 14/10/2011 22:15, Vitaly Savickas wrote:
> Hi Ed,
>
> I am sorry for probably a silly question - I didn't get why you
> mentioned a resource. Do you mean somehow watching for a read of a
> script file? I believe it is read every time I execute the script, as
> I programmatically create the TransformationExecutor and pass a script
> URI to it, then execute the executor and save the result.
>
> Shall I be more precise about my observation, what I meant is that
> after twiddling with the main script file I have commented most of the
> rule calls and include statements of libraries. Transformation ran
> quite fast, obviously:) Now when I uncommented includes so that the
> whole script to be read became huge, the speed decreased
> significantly. I don't see a reason in this case to have an increase
> in matching loop search time - I include the libraries, but don't use
> them:) Basically I have around 8 or so script files - one with with
> only a main rule and rest are libraries that are included and used in
> main. All rules are in libraries.
>
> So I guess there is no way to prepare the script once and cache or
> save it in this state for later executions so to speed them up? Very
> disappointing:(
>
> Regards,
> Vitaly
|
|
| | | |
Re: [QVTO] Any way to speed up transformation? [message #737781 is a reply to message #737774] |
Sat, 15 October 2011 12:39 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Ed Willink![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=ed%40willink.me.uk) Messages: 7681 Registered: July 2009 |
Senior Member |
|
|
Hi
QVTo is Open Source Software. You can run it under the debugger, set
breakpoints on interesting events, add println()'s for diagnostics.
Regards
Ed Willink
On 15/10/2011 13:30, Vitaly Savickas wrote:
> Sorry, Ed:) I fully understand your critique and agree with that. But
> I don't see a lot of power in the hands of a developer in this case,
> to be honest. The only thing I can control is to rewrite/restructure
> the script files. That's why I initially asked if I have control over
> the transformation workflow & can I optimise it by any other means
> than just script file content itself. It seems quite obvious from my
> experiments that what is happening is the bigger the size of the
> script files, the worse is performance, independing of the actual
> rules used/called - this isn't good. And what I can do about it - I
> guess nothing, as I use all the rules in the final product. But this
> doesn't mean the performance is bad because of the big number of
> rules, but because they are read every time on execution. And this is
> where I have no control to improve something. But I would be very
> happy if I am wrong:) That's why I asked about optimisation in the
> first place.
>
> Regards,
> Vitaly
|
|
|
Goto Forum:
Current Time: Wed Feb 05 19:13:43 GMT 2025
Powered by FUDForum. Page generated in 0.27368 seconds
|