Epsilon is a family of Java-based scripting languages for automating common model-based software engineering tasks, such as code generation, model-to-model transformation and model validation, that work out of the box with EMF (including Xtext and Sirius), UML (including Cameo/MagicDraw), Simulink, XML and other types of models.
Currently, @cached only supports 0-argument context operations, as the cache key only has the context object and the operation name. This is also done to limit the size of the cache: the current @cache is just a Java Map with no eviction policy (which guarantees that a @cached operation is only ever run once). Without an eviction policy, adding parameters to the cache key could dramatically increase the size of the cache if we are not careful.
It would be good to introduce an alternative configuration where @cached is backed by a Guava Cache instead of a Java Map, with a configurable bounded size and with an LRU eviction policy. This new approach could support operations with parameters, but would drop the guarantee that a @cached operation is only ever run once (as a less-used entry may be evicted at some point and may need to be recomputed).
To preserve backwards compatibility in Epsilon 2.x, we should keep the old no-eviction cache as the default behaviour. We may want to reconsider this default in a future 3.x release.
This issue would need both changing the EOL code, as well as extending the .dt plugins to allow for setting whether we want the old no-eviction cache (which only supports 0-arg operations), or the new LRU cache (which supports all operations).
Currently,
@cachedonly supports 0-argument context operations, as the cache key only has the context object and the operation name. This is also done to limit the size of the cache: the current@cacheis just a Java Map with no eviction policy (which guarantees that a@cachedoperation is only ever run once). Without an eviction policy, adding parameters to the cache key could dramatically increase the size of the cache if we are not careful.It would be good to introduce an alternative configuration where
@cachedis backed by a Guava Cache instead of a Java Map, with a configurable bounded size and with an LRU eviction policy. This new approach could support operations with parameters, but would drop the guarantee that a@cachedoperation is only ever run once (as a less-used entry may be evicted at some point and may need to be recomputed).To preserve backwards compatibility in Epsilon 2.x, we should keep the old no-eviction cache as the default behaviour. We may want to reconsider this default in a future 3.x release.
This issue would need both changing the EOL code, as well as extending the
.dtplugins to allow for setting whether we want the old no-eviction cache (which only supports 0-arg operations), or the new LRU cache (which supports all operations).