[viatra-dev] Metamodel provider update

[Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>]

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.