Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 463226

Summary: Make AQL Interpreter ready for prime time
Product: [Modeling] Sirius Reporter: Cedric Brun <cedric.brun>
Component: CoreAssignee: Project inbox <sirius.core-inbox>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: laurent.redor, pierre-charles.david
Version: unspecifiedKeywords: triaged
Target Milestone: 3.0.0   
Hardware: PC   
OS: Linux   
See Also: https://git.eclipse.org/r/43726
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=cd9877b378fb7b96d9f6a13ca88fa2c7083c16ed
https://git.eclipse.org/r/46344
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e51133e134c5047181da9ad6d6526a46dd4f8ea3
https://git.eclipse.org/r/46789
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=5e10bb747e192349d56fd51f3f55d68ba94fec5f
https://git.eclipse.org/r/47184
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=65108f46161e6870df69982a296679913dd00314
https://git.eclipse.org/r/47460
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=d73c529a2710ea78d8ed5756b8568565bae7b448
https://git.eclipse.org/r/47846
https://git.eclipse.org/r/47848
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=fa925110c5c5098f7d4937bbc2a659b53b4b1099
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=f613b0274cd8471ede53929d23c0b0c9e950d048
Whiteboard:
Bug Depends on: 468465    
Bug Blocks:    
Attachments:
Description Flags
projects to run the benchmark none

Description Cedric Brun CLA 2015-03-26 13:12:30 EDT
This is a ticket used to keep track of the code improvements required in the AQL support which got introduced with M6.
Comment 2 Eclipse Genie CLA 2015-04-23 09:20:58 EDT
New Gerrit change created: https://git.eclipse.org/r/46344
Comment 4 Pierre-Charles David CLA 2015-04-23 09:57:41 EDT
What about documentation? On the language itself (and its differences/restrictions compared to MTL) and on the Sirius integration.
Comment 5 Cedric Brun CLA 2015-04-23 10:11:38 EDT
It is going to come at some point. Hopefully before RC1 but we'll clearly prioritize the implementation if we have too. It is always possible to publish the documentation on the website as a "workaround" even after the release (I'm not saying I want that, just that we might have to make this decision)

Here is a tentative list of the content with a fairly high priority so that Specifiers can start feeling confident using this implementation.
- Migrating from Acceleo2 to AQL
- Migrating from MTL to AQL
- Language and services reference : syntax, operators, priorities

Anything else from your POV ?
Comment 6 Pierre-Charles David CLA 2015-04-23 11:33:19 EDT
(In reply to Cedric Brun from comment #5)
> It is going to come at some point. Hopefully before RC1 but we'll clearly
> prioritize the implementation if we have too. It is always possible to
> publish the documentation on the website as a "workaround" even after the
> release (I'm not saying I want that, just that we might have to make this
> decision)
> 
> Here is a tentative list of the content with a fairly high priority so that
> Specifiers can start feeling confident using this implementation.
> - Migrating from Acceleo2 to AQL
> - Migrating from MTL to AQL
> - Language and services reference : syntax, operators, priorities
> 
> Anything else from your POV ?

Not strictly documentation, but some performance numbers comparing A2/MTL/AQL, to quantify how faster AQL is compared to previous languages, and "sell" it to existing users.
Comment 7 Cedric Brun CLA 2015-04-23 11:38:27 EDT
> Not strictly documentation, but some performance numbers comparing
> A2/MTL/AQL, to quantify how faster AQL is compared to previous languages,
> and "sell" it to existing users.

I see.  We'll get to that at some point too and have an infrastructure in place to get those measures. In the meantime, the "my VSM now has a meaningful validation" is also a strong selling point for long time users, we should not forget that neither.
Comment 8 Eclipse Genie CLA 2015-04-29 10:39:32 EDT
New Gerrit change created: https://git.eclipse.org/r/46789
Comment 10 Eclipse Genie CLA 2015-05-05 10:02:51 EDT
New Gerrit change created: https://git.eclipse.org/r/47184
Comment 11 Cedric Brun CLA 2015-05-06 03:59:39 EDT
(In reply to Pierre-Charles David from comment #6)
> (In reply to Cedric Brun from comment #5)
> > It is going to come at some point. Hopefully before RC1 but we'll clearly
> > prioritize the implementation if we have too. It is always possible to
> > publish the documentation on the website as a "workaround" even after the
> > release (I'm not saying I want that, just that we might have to make this
> > decision)
> > 
> > Here is a tentative list of the content with a fairly high priority so that
> > Specifiers can start feeling confident using this implementation.
> > - Migrating from Acceleo2 to AQL
> > - Migrating from MTL to AQL
> > - Language and services reference : syntax, operators, priorities
> > 
> > Anything else from your POV ?
> 
> Not strictly documentation, but some performance numbers comparing
> A2/MTL/AQL, to quantify how faster AQL is compared to previous languages,
> and "sell" it to existing users.

For reference, here are some performance benchmarking results which I published yesterday (graphic is here: https://twitter.com/bruncedric/status/595608262755655681)

The procedure is  : measuring the refresh time of a diagram using Yourkit in tracing mode, with a DiagramDescription for each interpreter, a fairly basic one which only rely on .ecore.

(I'm attaching the projects required to reproduce this, you will also need to install EcoreTools 3.0.0M7 minimum).

But even in such a fairly simple use case (MTL and Query Legacy are known to have an overhad which increases significatively when the number of metamodels/complexity of metamodels goes up) AQL outperform both being 3 times faster than  <%%> and 4 times faster than [/]. And that's before we did specific work in optimising AQL itself. One notable thing in this diagram, is that <%%> has the fastest eAllContents compared to all the other implementations, this is because it is based on a fairly smart algorithm which prune subtrees based on an analysis of the Ecore models. That's something we'll port to AQL at some point.
One can also see that AQL does not introduce a significant overhead compared to service: and in most cases the overhad compared to feature: can also be overlooked compared to the flexibility you have with the language : we're in the 0 to 5% range of time spent in the query implementation when 100% is a diagram refresh.
Comment 12 Cedric Brun CLA 2015-05-06 04:00:10 EDT
Created attachment 253204 [details]
projects to run the benchmark
Comment 14 Eclipse Genie CLA 2015-05-07 12:16:38 EDT
New Gerrit change created: https://git.eclipse.org/r/47460
Comment 16 Eclipse Genie CLA 2015-05-13 10:00:22 EDT
New Gerrit change created: https://git.eclipse.org/r/47846
Comment 17 Eclipse Genie CLA 2015-05-13 10:04:49 EDT
New Gerrit change created: https://git.eclipse.org/r/47848
Comment 20 Pierre-Charles David CLA 2015-06-18 05:18:22 EDT
This was actually fixed for Sirius 3.0 and Acceleo 3.6 (both released with Eclipse Mars). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=470460 for the followup work needed to make AQL the primary query language recommended by Sirius.
Comment 21 Pierre-Charles David CLA 2015-06-24 11:12:39 EDT
Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0.