Eclipse Community Forums: M2M (model-to-model transformation) » [QVTO] Transformation performance degradation

Help

Home

Home » Archived » M2M (model-to-model transformation) » [QVTO] Transformation performance degradation

Show: Today's Messages :: Show Polls :: Message Navigator

[QVTO] Transformation performance degradation [message #481964]

Mon, 24 August 2009 21:39

Alex Mising name

Messages: 51
Registered: August 2009

Member

First time on the forum. Thank you for high quality software and quick responses!

We've run into a performance degradation issue, surfacing on larger models. The runtime performance of any given mapping appears to degrade with the number of times it is executed. This can be demonstrated with the transform appended below, which uses a single contextual paremeterless mapping 20000 times (and no, we don't really need to generate 20K Ecore classes ... Wink

, producing the following output:

Last 2000 took 468 ms
Last 2000 took 1279 ms
Last 2000 took 2528 ms
Last 2000 took 5335 ms
Last 2000 took 8783 ms
Last 2000 took 11684 ms
Last 2000 took 14446 ms
Last 2000 took 17035 ms
Last 2000 took 19562 ms
Last 2000 took 22152 ms
Total: 103287 ms

As far as I can tell, this is related to the performance of trace generation and lookup. It looks like there are two potential issues:

1) The collections used internally to collect traces appear to enforce uniqueness, which slows down adding new traces as the number of traces in the collection grows. In my experiments the use of addUnique instead of add (which also requires a cast to the collection type that exposes addUnique) appears to speed things up significantly. As far as I can tell at this point it is already known that the new trace is unique, so using addUnique is appropriate.

2) The generation/lookup of contextual parameterless traces is supposed to be optimized via a dedicated hash, but it looks like this mechanism is defeated by falling through to sequential search in other trace collections when there is no match - which routinely happens for any new mapping. Is this a bug? Shouldn't not finding it in hash be conclusive for this type of mapping?

With experimental fixes for these, the same transform runs ~120 times faster:

Last 2000 took 62 ms
Last 2000 took 94 ms
Last 2000 took 78 ms
Last 2000 took 78 ms
Last 2000 took 94 ms
Last 2000 took 93 ms
Last 2000 took 94 ms
Last 2000 took 78 ms
Last 2000 took 93 ms
Last 2000 took 94 ms
Total: 858 ms

Could somebody please have a look at this?

Thank you,
Alex

Edit: Appended QVT transformation code as attachments don't seem to be working in the forum ...

import emf.tools;
modeltype Ecore "strict" uses 'http://www.eclipse.org/emf/2002/Ecore';

transformation test(out model : Ecore);

main() {
	var start := this.currentTimeMillis();
	var i:= 0, s := this.currentTimeMillis();
	while(i<20000)
 	{
		i := i + 1;
		i.map ToClass();
		if i.mod(2000)=0 then 
		{
			log('Last 2000 took ' + (this.currentTimeMillis()-s).toString() + ' ms');
			s := this.currentTimeMillis();
		} 
		endif;
	};
	log('Total: ' + (this.currentTimeMillis()-start).toString() + ' ms');
}

mapping Integer::ToClass() : EClass
{
    name := 'c' + self.toString();
}

[Updated on: Tue, 25 August 2009 17:42]

Report message to a moderator

Re: [QVTO] Transformation performance degradation [message #482046 is a reply to message #481964]

Tue, 25 August 2009 08:36

Alex Mising name

Messages: 51
Registered: August 2009

Member

I have edited the original message on the forums adding the code
demonstrating the issues, but it looks like edits are not propageted to
the newsgroups, so here it is again:

import emf.tools;
modeltype Ecore "strict" uses 'http://www.eclipse.org/emf/2002/Ecore';

transformation test(out model : Ecore);

main() {
var start := this.currentTimeMillis();
var i:= 0, s := this.currentTimeMillis();
while(i<20000) {
i := i + 1;
i.map ToClass();
if i.mod(2000)=0 then {
log('Last 2000 took ' + (this.currentTimeMillis()-s).toString() + '
ms');
s := this.currentTimeMillis();
} endif;
};
log('Total: ' + (this.currentTimeMillis()-start).toString() + ' ms');
}

mapping Integer::ToClass() : EClass
{
name := 'c' + self.toString();
}

Report message to a moderator

Re: [QVTO] Transformation performance degradation [message #482129 is a reply to message #481964]

Tue, 25 August 2009 13:01

Eclipse User

Originally posted by: dvorak.radek.gmail.com

Hi Alex,

Thanks for spending time on this, we will take a look at this problem asap.
It definitely looks like the time to optimize has come ;-).

Would you mind raising a bugzilla on this, attaching your experimental
fixes?
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2M& component=QVT_OML-Engine

Regards,
/Radek

On Mon, 24 Aug 2009 23:42:27 +0200, Alex <alex.leites@gmail.com> wrote:

> First time on the forum. Thank you for high quality software and quick
> responses!
>
> We've run into a performance degradation issue, surfacing on larger
> models. The runtime performance of any given mapping appears to degrade
> with the number of times it is executed. This can be demonstated with
> the attached transform, which uses a single contextual paremeterless
> mapping 20000 times (and no, we don't really need to generate 20K Ecore
> classes ... ;), producing the following output:
>
> Last 2000 took 468 ms
> Last 2000 took 1279 ms
> Last 2000 took 2528 ms
> Last 2000 took 5335 ms
> Last 2000 took 8783 ms
> Last 2000 took 11684 ms
> Last 2000 took 14446 ms
> Last 2000 took 17035 ms
> Last 2000 took 19562 ms
> Last 2000 took 22152 ms
> Total: 103287 ms
>
> As far as I can tell, this is related to the performance of trace
> generation and lookup. It looks like there are two potential issues:
>
> 1) The collections used internally to collect traces appear to enforce
> uniqueness, which slows down adding new traces as the number of traces
> in the collection grows. In my experiments the use of addUnique instead
> of add (which also requires a cast to the collection type that exposes
> addUnique) appears to speed things up significantly. As far as I can
> tell at this point it is already known that the new trace is unique, so
> using addUnique is appropriate.
>
> 2) The generation/lookup of contextual parameterless traces is supposed
> to be optimized via a dedicated hash, but it looks like this mechanism
> is defeated by falling through to sequential search in other trace
> collections when there is no match - which routinely happens for any new
> mapping. Is this a bug? Shouldn't finding it in hash be conclusive for
> this type of mapping?
>
> With experimental fixes for theses, the same transform runs ~120 times
> faster:
>
> Last 2000 took 62 ms
> Last 2000 took 94 ms
> Last 2000 took 78 ms
> Last 2000 took 78 ms
> Last 2000 took 94 ms
> Last 2000 took 93 ms
> Last 2000 took 94 ms
> Last 2000 took 78 ms
> Last 2000 took 93 ms
> Last 2000 took 94 ms
> Total: 858 ms
>
> Could somebody please have a look at this?
>
> Thank you,
> Alex

Report message to a moderator