Configures the
ImpactAnalyzer and the
InstanceScopeAnalysis components and choose between different
implementation styles. A singleton instance of this class is managed by
OptimizationActivation. The following options
can be configured, either by invoking a setter or by passing the respective argument to the constructor:
- deltaPropagationActive (see
isDeltaPropagationActive() and setDeltaPropagationActive(boolean):
Tells if the instance scope analysis shall use a delta propagation and partial evaluation mechanism to decide early on if the
subexpression(s) immediately affected by the change may propagate the change all the way to the overall expression's evaluation
result. This will trigger OCL evaluations for subexpressions, some of which may fail for unknown variables, some of which may
prove that the subexpression where the change "hit" doesn't propagate the change, leaving the overall expression unchanged. By
and large, this saves significant efforts during re-evaluation as it reduces the set of context instances returned by
ImpactAnalyzer.getContextObjects(org.eclipse.emf.common.notify.Notification) for many cases. Our measurements show that
the additional efforts spent for the analysis gets amortized in all cases we have measured. Recommendation: set to
true.
- tracebackStepISAActive: (see
isTracebackStepISAActive() and setTracebackStepISAActive(boolean):
Currently, there are two fundamentally different implementation strategies for the instance scope analysis (see also
InstanceScopeAnalysis). One pre-computes one step object per (sub-)expression contained in the
OCL expression's AST and executes them when
ImpactAnalyzer.getContextObjects(org.eclipse.emf.common.notify.Notification) is invoked. This strategy lends itself
well for an additional early pruning of options related to the unusedDetectionActive option explained below. If
deselected by setting this option to false, a strategy is selected which materialized only those
steps that actually perform some navigation or filtering on the model graph. The construction of this
tree, according to our measurements, is slightly more expensive than the construction of the more
elaborate step graph. On average, the two perform fairly similar. The key difference, as already mentioned, is that only when
setting this option to true, the unusedDetectionActive option has any effect.
- unusedDetectionActive (see
isUnusedDetectionActive() and setUnusedDetectionActive(boolean):
Activates a performance improvement measure which aims to prove that the sub-expression where the change occurred is not used
under the variable/parameter/self settings inferred from the information delivered about the change in the change
Notification. For example, if a change occurs in an else branch of an if-expression and the
condition can be proven to evaluate to true based on the information taken from the Notification, this
proves that the subexpression that changed its value is not used in evaluating the overall expression. Therefore, the change
does not impact the overall expression at all. This technique involves some up-front cost for determining the various checks to
be performed. During ImpactAnalyzer.getContextObjects(org.eclipse.emf.common.notify.Notification) some additional cost
is incurred for evaluating sub-expressions (such as an if-expression's condition, as exemplified above). For
smaller models, performance seem to be on-par for both settings of this switch. We hope to prove that for certain cases where
we see really bad performance without this option being used, using it would significantly shrink the number of elements
considered to potentially have changed. This option can only be selected, if isTracebackStepISAActive()
is true.
- operationCallSelectionActive (see
isOperationCallSelectionActive() and
setOperationCallSelectionActive(boolean): Activates a performance improvement measure which aims to minimize
the OperationCallExp considered when tracing back through a self or parameter variable inside an
operation body. Without this measure, all results obtained from tracing back through all possible calls to the
operation considered will be used. With the measure activated, while all results will be computed and cached,
only those specific to the call considered will be used further on. This makes the results crisper and smaller but
may consume a little more performance during evaluation time because results need to be keyed by OperationCallExp
expressions, causing more data structures to be maintained. This option can only be selected, if isTracebackStepISAActive()
is true.