Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Is there a caching version of org.eclipse.ocl.AbstractEnvironment?
Is there a caching version of org.eclipse.ocl.AbstractEnvironment? [message #707850] Tue, 02 August 2011 06:17 Go to next message
Nicolas Rouquette is currently offline Nicolas RouquetteFriend
Messages: 142
Registered: July 2009
Senior Member
The Eclipse QVTO compiler is built as an extension of Eclipse OCL.

The Eclipse QVTO compiler works roughly in 3 phases:
1) parsing
2) import resolution
3) symbol/type analysis

During the third phase, symbol/type analysis, the QVTO compiler bangs quite hard on the OCL evaluator.

In particular, there are lots of calls to org.eclipse.ocl.AbstractEnvironment.lookup*()
and tryLookup*() methods.

Is there a caching version of this mechanism to speed up repeated calls to the same environment for the same method parameter values?

- Nicolas.
(no subject) [message #707879 is a reply to message #707850] Tue, 02 August 2011 07:00 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi Nicolas

Simple answer: No.

In principle it would seem easy, but the complexities of nested
environments make life hard, and there is a tradeoff between mega- and
trivial use.

If your OCL expression is "true", do you really want all the caching
overhead?

You can provide your own EnvironmentFactory and consequently your own
derived AbstractEnvironment with a cache, and if you make sure
that the environment is reused for multiple compatible parses the cache
could be pretty amazing.

Hm.. not so sure. I see obscure nightmares. You will have to handle
hierarchy carefully otherwise the cache could corrupt QVTo's marginally
specified name visibility rules. The Environments support nested scopes
and this is used by QVTd, unfortunately the mature code does not use
them preferring the 'more efficient' add/remove of variables by name.

Clearly this is useful to QVTo that knows it will do a lot of parsing in
one environment. Perhaps 'QVTo' might like to develop a caching environment
and contribute it to OCL.

The new pivot code has flattened dispatch tables for fast evaluation.
Whether these materialize as caches at compile time is not clear. Your
pushing me in that direction.

Regards

Ed Willink

On 02/08/2011 07:17, Nicolas Rouquette wrote:
> The Eclipse QVTO compiler is built as an extension of Eclipse OCL.
>
> The Eclipse QVTO compiler works roughly in 3 phases:
> 1) parsing
> 2) import resolution
> 3) symbol/type analysis
>
> During the third phase, symbol/type analysis, the QVTO compiler bangs
> quite hard on the OCL evaluator.
>
> In particular, there are lots of calls to
> org.eclipse.ocl.AbstractEnvironment.lookup*()
> and tryLookup*() methods.
>
> Is there a caching version of this mechanism to speed up repeated
> calls to the same environment for the same method parameter values?
>
> - Nicolas.
Previous Topic:oclIsTypeOf error with OCLinEcore
Next Topic:[OclInEcore] imported files not recognized
Goto Forum:
  


Current Time: Sun Dec 21 20:11:32 GMT 2014

Powered by FUDForum. Page generated in 0.01632 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software