[evaluator] Introduce a LazyCollectionValue

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 339783 | | Status | NEW | | Importance | P3 enhancement | | Reported | Mar 12, 2011 06:04 EDT | | Modified | Jan 11, 2019 06:12 EDT | | Version | 3.1.0 | | Blocks | 509668, 543368 | | See also | 341944 | | Reporter | Ed Willink |

Description

The iterators do a nice job of avoiding large intermediate collections by using Iterables instead.

This policy could be usefully extended to work across let variables. The source expression can return a LazyCollectionValue wrapping an Iterable, deferring the source calculation. The recipient then can then iterate over the collection if that is all that is wanted. It is only if operations such as size() are invoked that the whole collection needs reifying.

A compile time analysis of the consumers of a let variable can use some simple heuristics to indicate whether a lazy collection may be beneficial.

[eclipse-ocl-bot]

By Ed Willink on Jan 23, 2012 01:51

(In reply to comment #0)

This policy could be usefully extended to work across let variables. The source expression can return a LazyCollectionValue wrapping an Iterable, deferring the source calculation. The recipient then can then iterate over the collection if that is all that is wanted. It is only if operations such as size() are invoked that the whole collection needs reifying.

No. A 'Collector' (an algorithm yielding a Collection from a Collection) can support optimisation of a cascade of Collectors and avoid reifying the intermediates.

size() in particular does not need a reification for Sequence or Bag; only for Set and OrderedSet of content with overloaded OclAny::= to verify uniqueness.

This could be particularly beneficial for access to Ecore's 'many' features since the EObject2ObjectValue Collector can avoid the creation of many EObjectValue creations.

For Istvan's SwitchSensor benchmark: self.TrackElement_sensor->isEmpty()\ A quick experiment with a delegating collection to avoid the unnecessary EObjectValue construction results in a 2-fold improvement for the interpreted Pivot evaluator and a 3-fold improvement for the code-generated evaluator, making the CG evaluator 5 times faster than the Ecore interpreted evaluator.

[eclipse-ocl-bot]

By Ed Willink on Nov 05, 2015 10:56

Java 8 streams provide much of the required functionality.

[eclipse-ocl-bot]

By Ed Willink on Dec 23, 2016 08:47

(In reply to Ed Willink from comment #0)

A compile time analysis of the consumers of a let variable can use some simple heuristics to indicate whether a lazy collection may be beneficial.

OCL expressions are much simpler. A lazily computed AST has exactly one consumer. It must be put into a VariableDeclaration to be multiply consumed. A static analysis of the opposite of VariableExp.referredVariable will detect multi-consumption.