|(no subject) [message #707879 is a reply to message #707850]
||Tue, 02 August 2011 07:00
| Ed Willink
Registered: July 2009
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
If your OCL expression is "true", do you really want all the caching
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.
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
> 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.
Powered by FUDForum
. Page generated in 0.12523 seconds