Re: [m2m-atl-dev] ATL Parser/Compiler performance: generate code for ATL

[Frédéric Jouault <f.jouault@xxxxxxxxx>]

Dear Dennis,

In general, and more especially with ATL, generating the code for a
metamodel is never required. Of course, it helps people who write
their transformations in Java, but even then it is not required.

However, if generating code for the ATL metamodel increases
performance, then it can simply be seen as an optimization. The danger
is that we start writing some Java code that relies on this generated
code.

I do believe that an optimized dynamic EMF combined with a better use
of it by ATL & TCS could lead to performance similar to what can be
achieved by generating code for ATL metamodel. Some of the latter
optimizations could probably still increase compilation performance,
even with generated metamodel code. But generating the code is clearly
a simple thing to do. So, since it increases compilation performance
at no development cost, I have no objection (provided we never
introduce code that rely on it).

Thanks for determining that generating ATL metamodel code increase
compilation performance significantly enough that doing it is useful.
And thanks for doing it as well ;-).

Have you put your profiling or some speed-up results somewhere (e.g.,
on bugzilla)? That could be useful.


Thanks,

Frédéric


On Thu, Nov 26, 2015 at 9:54 AM, Dennis Wagelaar <dwagelaar@xxxxxxxxx> wrote:
> Dear devs,
>
> At HealthConnect we've been suffering from slow ATL parser and compiler
> performance for a while now. Splitting up ATL files only gets you so far,
> and a complete project rebuild takes half a minute. JMGauthier's comment on
> http://modeling-languages.com/whats-wrong-with-atl-or-model-transformation-languages-in-general/
> triggered some action on my behalf.
>
> I did some profiling of where most CPU time was spent during parsing and
> compiling, and found that it was because of the reflective Ecore model for
> ATL (and Problem). Therefore, I've gone ahead and generated (minimal) code
> for ATL.ecore and Problem.ecore:
>
> http://git.eclipse.org/c/mmt/org.eclipse.atl.git/commit/?id=9496f0f2e889dd77a3497674624543b74a11122c
>
> This should not change anything in the ATL API, so no breaking changes. If
> you have any comments, please let me know!
>
> Kind regards,
> Dennis Wagelaar
>
> _______________________________________________
> m2m-atl-dev mailing list
> m2m-atl-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev