Re: [viatra-dev] Metamodel provider update

[Bergmann Gábor <bergmann@xxxxxxxxxx>]

Hi,

I believe one of the most serious woes of the current tooling is the long 
stalls that happen during the editing of vql files.
Even if there is no large impact of batch build performance, is it possible 
that your change successfully eliminated or reduced the recomputations 
necessary for these frequent and annoying pauses?

Thanks
Gábor


-----Original Message----- 
From: Zoltán Ujhelyi
Sent: Wednesday, August 30, 2017 11:36 AM
To: Viatra project developer discussions
Subject: [viatra-dev] Metamodel provider update

Hi all,

during the last meeting I have mentioned that I am working on a prototype 
editor for VIATRA Queries that uses Xtext index for resolving metamodel 
references. I have finally managed to execute some preliminary performance 
measurements on a large (but proprietary) project with several hundred 
patterns on build times, and tried to use the editor to have a feel for the 
performance of the editor, content assist, etc.

I have compared the performance of VIATRA 1.6.1 release, both the default 
version and with the optional target platform caches by measuring the time 
of cleaning and building the pattern projects.  For measurements I have not 
created any setup, just looked at the time when the build was started and 
stopped. The results were the following:

* 1.6.1 (default): 7 minutes
* 1.6.1 (with cache): 4 minutes
* 1.7.0 (prototype): 3-4 minutes (a little bit better than the caching 
solution, but the difference is small enough that it can be a measurement 
error).

When testing the responsiveness of the editor, basically the prototype 
editor is about as snappy as the one with the caches (which means slow, but 
usable); while with the default behaviour it is unusable (e.g. you have to 
wait a minute or more for the response).

——

The question is now whether it is worth to continue the work with the 
prototypes, as there is still work to be done before it would be ready for 
use. I see the following benefits and issues based on the existing work:

* Benefits
  * We can remove the entire metamodel provider infrastructure. This has 
multiple benefits:
     * The code is complex and error-prone; I hope this will increase the 
stability of the codebase.
     * We might possibly remove support for the vqgen files, as they will 
not be used anymore.
     * Hopefully we will be compatible with the generic Maven and Gradle 
plug-ins of Xtext, and thus VIATRA can be used in Gradle projects as well. 
(Not tested!)
  * We could provide a better import management for VIATRA. Basically, we 
might switch to import classifiers one-by-one, and then the required 
declarations could easily be added by content assist, similar to the Java 
and Xtext editors.
* Issues, future tasks
  * Backward compatibility with old versions is problematic, as I cannot 
find the classes/packages are not cached by nsURIs but Java qualified names 
into the index (not exactly but close enough). I see two potential solution 
for this issue:
    1. We include both the old and new import; and make sure the old code 
is not executed when only the new import syntax is used, and provide some 
tooling to gradually migrate everything. This can become quite complex.
    2. We explicitly break compatibility, and provide a (hopefully) 
automatic migration tooling; however, end users might be less likely to 
upgrade because of this.
  * I have not tested yet how well does this approach work when the 
genmodel is missing (e.g. not included in the plug-ins, etc.). There might 
be some issues there that might require further research or experiments.
  * There are some features in the current prototype that were turned off, 
as they were not required to the first prototype version, e.g. right now the 
ecore/genmodel files have to be available in a source folder, and some 
validations are turned off. These features can be turned back on, just some 
more work is necessary.


——

To summarize, I am not sure whether it is worth pursuing this prototype any 
further, as we have already a cheaper but backward compatible alternative 
with basically the same performance; and I don’t know whether the other 
benefits outweigh the implementation costs. What do you think?

Best regards,
Zoli
-- Zoltán Ujhelyi

Eclipse Technologies Expert
IncQueryLabs Ltd.

_______________________________________________
viatra-dev mailing list
viatra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/viatra-dev