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

Bug 339783

Summary: [evaluator] Introduce a LazyCollectionValue
Product: [Modeling] OCL Reporter: Ed Willink <ed>
Component: CoreAssignee: OCL Inbox <mdt-ocl-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: eclipse
Version: 3.1.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=341944
Whiteboard:
Bug Depends on:    
Bug Blocks: 509668, 543368    

Description Ed Willink CLA 2011-03-12 06:04:21 EST 
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.
Comment 1 Ed Willink CLA 2012-01-23 01:51:10 EST 
(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.
Comment 2 Ed Willink CLA 2015-11-05 10:56:30 EST 
Java 8 streams provide much of the required functionality.
Comment 3 Ed Willink CLA 2016-12-23 08:47:44 EST 
(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.