[news.eclipse.modeling.m2m] [QVTO] Transformation performance degradatio

[Alex <alex.leites@xxxxxxxxx>]

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