Index: /reasoner/reasoner.tex =================================================================== --- /reasoner/reasoner.tex (revision 75) +++ /reasoner/reasoner.tex (revision 76) @@ -6,4 +6,5 @@ \usepackage[ruled, vlined]{algorithm2e} \usepackage{graphicx} +\usepackage{adjustbox} \newcommand\TBD[1]{{\color{blue}TBD: #1}} @@ -189,5 +190,5 @@ For some purpose, the reasoning mechanism must classify constraints, in particular default value assignments over usual constraints. We indicate this information as a `$d$' in the constraint creation notation, i.e., for creating a default constraint, we denote $\createDefaultConstraint{\IVML{assign}(x, 25)}$ -In some cases, expressions used to build up a constraint are created before the actual constraint and stored in structures for lookup. We denote the creation of an expression by $\createExpression{expr}$, e.g., $\createExpression{\IVML{add}(x, 25)}$ for calculating the sum of $x$ and 25. Thereby, sometimes the creation of temporary (local) variables, e.g., for an IVML let-expression or a container iterator is required. We state this by $\IVMLMeta{var}(i, t)$, i.e., create the temporary variable $i$ of type $t$. For a variable $v$ created by \IVMLMeta{var} holds $isLocal(v) = true$. A specific type of expression is the constant, which holds an IVML value. The operation $const(e)$ returns the value of $e$ if $e$ is a constant expression or $\undef$ otherwise. +In some cases, expressions used to build up a constraint are created before the actual constraint and stored in structures for lookup. We denote the creation of an expression by $\createExpression{expr}$, e.g., $\createExpression{\IVML{add}(x, 25)}$ for calculating the sum of $x$ and 25. A specific type of expression is the constant, which holds an IVML value. The operation $const(e)$ returns the value of $e$ if $e$ is a constant expression or $\undef$ otherwise. When creating expressions, sometimes a temporary (local) variable is needed, e.g., for an IVML let-expression or a container iterator. We state this by $\IVMLMeta{var}(t)$, i.e., create the temporary variable of type $t$ (we don't care for the name of the variable here). For a variable $v=\IVMLMeta{var}(t)$ holds $isLocal(v) = true$. \subsubsection{Compounds}\label{sectNotationCompounds} @@ -627,6 +628,9 @@ Algorithm \ref{algTranslateContainerDeclaration} performs the transformation for a container variable declaration $d$ of variable $v$, if nested with given access expression $ca$ and specific type $t$ (due to a known default value). First, we determine the innermost nested type $t_n$ and its base type $t_b$ (taking derived types into account) as well as the relevant value $val$. If $v$ is a constraint container, i.e., the innermost nested base type is a constraint, we collect and translate all constraints constituted by all (flattened) element values in line \ref{algTranslateContainerDeclarationConstraintContainer}. If $v$ is a compound container, i.e., the innermost nested base type is a compound, we try to derive as many relevant constraints as possible. Therefore, we determine the used contained compound types in line \ref{algTranslateContainerDeclarationUsedTypesDefault}. For all these types, we determine all default value constraints using Algorithm \ref{algTranslateDefaultsCompoundContainer} in lines \ref{algTranslateContainerDeclarationCompoundContainerDefaultsStart}-\ref{algTranslateContainerDeclarationCompoundContainerDefaultsEnd}. Moreover, for all used most specific compound types, we collect and instantiate all compound-related constraints using Algorithm \ref{algTranslateCompoundContainer2} in lines \ref{algTranslateContainerDeclarationCompoundContainerUsedCompoundsStart}-\ref{algTranslateContainerDeclarationCompoundContainerUsedCompoundsEnd}. As Algorithm \ref{algTranslateCompoundContainer2} takes all refined compounds into account, we leave out the refined types from the used containers in line \ref{algTranslateContainerDeclarationCompoundContainerUsedCompoundsStart}. For the remaining, not already translated compound types, we also apply Algorithm \ref{algTranslateCompoundContainer2}, here through Algorithm \ref{algTranslateCompoundContainer} (based on the configured value) in line \ref{algTranslateContainerDeclarationCompoundContainerCompounds}. Independently of constraint or compound container, we finally translate and collect all constraints stemming from derived type definitions in line \ref{algTranslateContainerDeclaration}. -%----------------------------------------------------------------------------------------------------------------- - +We turn now to the algorithms that were used by Algorithm \ref{algTranslateContainerDeclaration}. + +Algorithm \ref{algTranslateDefaultsCompoundContainer} creates constraints for default value instantiation of compound values directly created in container initializers, e.g., in IVML something like \IVML{seq = \{\{i=1\}, \{i=2\}\}}, assuming that \IVML{seq} is a sequence of compounds, which have an integer slot \IVML{i}. As these compounds are created implicitly within a container initializer, so far no default value constraints are created and scheduled to the constraint base, i.e., these compounds would remain uninitialized. Algorithm \ref{algTranslateDefaultsCompoundContainer} solves this by creating all-quantized constraints over all elements of the container applying the default value expressions to the elements. Utilizing quantor constraints here implies that default initializations, which remain undefined if some dependent variables have not been determined so far, cause a re-evaluation for all elements of the container. Here, unfolding the implicit loop of such a quantor may be a solution, as then only individual constraints are triggered. However, this only works for sequences, as sets do not provide element-wise/index-based access and unfolding the constraint for a large container also may create a huge number of constraints. Currently, we stay with the compromise of creating a single quantized constraint for all slots with default values. + +Algorithm \ref{algTranslateDefaultsCompoundContainer} creates the constraint in incremental fashion, considering several special cases but also allowing for optimization. Here, $d$ is a container variable declaration, $t$ the compound type to be processed, i.e., the innermost basic type of $type(d)$ or one of its refining compound types. For each constraint with default values of a given type, we create in line \ref{algTranslateDefaultsCompoundContainerInitE} an expression just holding the variable of the container $d$. If the container is nested, we flatten it in line \ref{algTranslateDefaultsCompoundContainerFlatten} as constraints only need to be created for the elements (no specific constraints can be attached to a container type except for derived values, which are handled by Algorithm \ref{algTranslateDeclaration}). If the actual type $t$ to be processed is not the same as the type of the declaration $type(d)$, we must consider that the slot $s$ only exists for the specific refined type $t$, i.e., the instantiation applies only to container elements of type $t$ (or of refined types), i.e., we insert in line \ref{algTranslateDefaultsCompoundContainerCast} a type selection \TBD{typeSelect, or kind?} operation projecting the container to all elements of type $t$. As preparation for creating the quantor constraint, we create in line \ref{algTranslateDefaultsCompoundContainerTemporary} the temporary iterator $i$ variable of type $t$ and substitute in line \ref{algTranslateDefaultsCompoundContainerSubst} the variables of the default value expression for $u$ according to the actual variable mapping, replacing also \IVMLself{} by $i$ (not slot $s$, which may be of any other type). Finally, we create in line \ref{algTranslateDefaultsCompoundContainerQuantor} the all-quantor for all typed elements $i$ assigning slot $s$ on $i$ the value defined by the substituted default value expression. \begin{algorithm}[H] @@ -635,9 +639,20 @@ \KwData{deferred default constraints $\deferredDefaultConstraints$} \ForAll{$s \iterAssng \setWith{dfltSlots(u)}{u \in allRefines^+(t)}$}{ - $add(\deferredDefaultConstraints, \createDefaultConstraint{\IVML{typeSelect}(\IVML{flatten}(d), t)\rightarrow \IVML{forAll}(\IVMLMeta{var}(i,t)|\IVML{assign}(i.name(s), \varSubstitutionSelfVarMapping{default(s)}{i})})$\; + $e\assng\createExpression{d}$\; \label{algTranslateDefaultsCompoundContainerInitE} + \uIf{$isNested(type(d))$} { + $e\assng\createExpression{\IVML{flatten}(d)}$\; \label{algTranslateDefaultsCompoundContainerFlatten} + } + \uIf{$type(d)\neq t$} { + $e\assng\createExpression{\IVML{typeSelect}(e, t)}$\; \label{algTranslateDefaultsCompoundContainerCast} + } + $i\assng\createExpression{\IVMLMeta{var}(t)}$\; \label{algTranslateDefaultsCompoundContainerTemporary} + $f\assng\varSubstitutionSelfVarMapping{default(s)}{i}$\; \label{algTranslateDefaultsCompoundContainerSubst} + $add(\deferredDefaultConstraints, \createDefaultConstraint{e\rightarrow \IVML{forAll}(i|\IVML{assign}(\IVML{acc}(i,name(s)), f)})$\; \label{algTranslateDefaultsCompoundContainerQuantor} } - \caption{Translating defaults in compound containers (\IVML{translateDefaultsCompoundContainer}).}\label{algTranslateDefaultsCompoundContainer} \end{algorithm} + +\MISSING{---HERE---} +%----------------------------------------------------------------------------------------------------------------- If $d$ is a container, we must translate and apply all constraints of compounds within that container \TBD{nested containers follow?} to $d$. As Algorithm \ref{algTranslateCompoundContainer} is used within different algorithms, we return the collected constraints here. @@ -829,59 +844,74 @@ \begin{table*}[h] +\begin{adjustbox}{angle=90} \centering -\begin{tabular}{|l|c||p{8cm}|} +\begin{tabular}{|l|c||p{8cm}|p{6cm}|} \hline -\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation} \\ +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation} & textbf{Test}\\ \hline -Decision variable & 2.1.4 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTranslationDeclaration} $\rightarrow$ Alg. \ref{algTranslateDeclaration}, \ref{algTranslateDeclarationTranslateDefault}; annotation defaults in line \ref {algTranslateDeclarationAnnotationDefault} $\rightarrow$ Alg. \ref{algTranslateAnnotationDefaults}\\ -Constraint & & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelConstraints} \\ -Annotation assignment & 2.2.2 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments} $\rightarrow$ Alg. \ref{algTranslateAnnotationAssignments} \\ -Partial evaluation & 2.2.5.3 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelEvals} \\ +Decision variable & 2.1.4 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTranslationDeclaration} $\rightarrow$ Alg. \ref{algTranslateDeclaration}, \ref{algTranslateDeclarationTranslateDefault}; annotation defaults in line \ref {algTranslateDeclarationAnnotationDefault} $\rightarrow$ Alg. \ref{algTranslateAnnotationDefaults} & \\ +Constraint & & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelConstraints} & \\ +Annotation assignment & 2.2.2 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments} $\rightarrow$ Alg. \ref{algTranslateAnnotationAssignments} & \\ +Partial evaluation & 2.2.5.3 & Alg. \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelEvals} & \\ \hline - \multicolumn{3}{|c|}{Types}\\ + \multicolumn{4}{|c|}{Types}\\ \hline -Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration}, line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg. \ref{algTranslateDerivedDatatypeConstraints} \\ -Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint} \\ -Compound type & 2.1.3.5 & complex value: Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateCompound} $\rightarrow$ Alg.\ref{algTranslateCompoundDeclaration} \\ -+ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg.\ref{algTranslateDerivedDatatypeConstraints} \\ -+ Compound type & 2.1.3.5 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateCompound} $\rightarrow$ Alg.\ref{algTranslateCompoundDeclaration} \\ -+ Container type & 2.1.3.3 & \\ -+ Derived Compound Type & & \\ -+ Derived Container Type & & \\ -+ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint} via compound access line \ref{algTranslateDeclarationTranslateInCompound} \\ -+ Constraint & 2.1.3.5 & \\ -+ Refined compounds & 2.2.3.1 & \\ -+ Partial evaluation & 2.2.5.3 & \\ -+ Assignment-block & 2.2.2 & \\ -Container type & 2.1.3.3 & complex value: Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateContainer} $\rightarrow$ Alg. \ref{algTranslateContainerDeclaration} \\ -+ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg.\ref{algTranslateDerivedDatatypeConstraints} \\ -+ Compound type & 2.1.3.5 & \\ -+ Container type & 2.1.3.3 & \\ -+ Derived Compound Type & & \\ -+ Derived Container Type & & \\ -+ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \TBD{constraint value} \\ -Annotation of & 2.2.2 & \\ -+ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Derived type & 2.1.3.4 & \\ -+ Compound type & 2.1.3.5& \\ -+ Container type & 2.1.3.3 & \\ -+ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} \\ -+ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}\\ +Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ +Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ +Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration}, line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg. \ref{algTranslateDerivedDatatypeConstraints} & \\ +Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ +Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint} & \\ +Compound type & 2.1.3.5 & complex value: Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateCompound} $\rightarrow$ Alg.\ref{algTranslateCompoundDeclaration} & \\ ++ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg.\ref{algTranslateDerivedDatatypeConstraints} & \\ ++ Compound type & 2.1.3.5 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateCompound} $\rightarrow$ Alg.\ref{algTranslateCompoundDeclaration} & \\ ++ Container type & 2.1.3.3 & & \\ ++ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint} via compound access line \ref{algTranslateDeclarationTranslateInCompound} & \\ \hline \end{tabular} +\end{adjustbox} \caption{IVML concepts vs. reasoning constraint transformations.} \label{tab:IVMLReasoner} \end{table*} + +\begin{table*}[h] +\begin{adjustbox}{angle=90} +\centering +\begin{tabular}{|l|c||p{8cm}|p{6cm}|} +\hline +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation} & textbf{Test}\\ +\hline ++ Constraint & 2.1.3.5 & & \\ ++ Refined compounds & 2.2.3.1 & & \\ ++ Partial evaluation & 2.2.5.3 & & \\ ++ Assignment-block & 2.2.2 & & \\ +Container type & 2.1.3.3 & complex value: Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateContainer} $\rightarrow$ Alg. \ref{algTranslateContainerDeclaration} & \\ ++ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Derived type & 2.1.3.4 & Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationDerivedDatatype} $\rightarrow$ Alg.\ref{algTranslateDerivedDatatypeConstraints} & \\ ++ Compound type & 2.1.3.5 & & \\ ++ Container type & 2.1.3.3 & & \\ ++ Derived Compound Type & & & \\ ++ Derived Container Type & & & \\ ++ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \TBD{constraint value} & \\ ++ Constraint Container& & & constraintSetDefault, constraintSetSetDefault \\ ++ Derived Constraint Container& & & \\ +Annotation of & 2.2.2 & & \\ ++ Basic type & 2.1.3.1 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Enum type & 2.1.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Derived type & 2.1.3.4 & & \\ ++ Compound type & 2.1.3.5& & \\ ++ Container type & 2.1.3.3 & & \\ ++ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \\ ++ Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}& \\ +\hline +\end{tabular} +\end{adjustbox} +\end{table*} + %----------------------------------------------------------------------------------------------------------------- @@ -891,16 +921,19 @@ \begin{itemize} - \item For lists of unknown size and for the expected capacity of IVML models, use \textbf{linked lists} instead of array lists. Main operations are adding, iterating over all, and removing elements to clean up memory incrementally, i.e., linked lists can avoid performance-impacting resizing effects. Index-based access is not needed, constraints are just added and one iteration is needed to build up the constraint base or to perform reasoning. Pre-calculation of the expectied size of the data structures per model seems to be unfeasible as this requires a second run over all model elements. + \item For lists of unknown size and for the expected capacity of IVML models, use \textbf{linked lists} instead of array lists. Main operations are adding, iterating over all, and removing elements to clean up memory incrementally, i.e., linked lists can avoid performance-impacting resizing effects. Index-based access is not needed, constraints are just added and one iteration is needed to build up the constraint base or to perform reasoning. Pre-calculation of the expected size of the data structures per model seems to be unfeasible as this requires a second run over all model elements. \item Process the \textbf{constraint base} iteratively and remove processed constraints directly after processing. This again requires a linked list as otherwise incremental resizing effects can affect the performance. In summary, building the constraint base and reasoning causes peak memory effects that are better from a performance point of view than (re-)allocating big array memory blocks. \item Avoid having too many unneeded \textbf{partitions of the constraint base} being stored during the translation in different lists, that are finally added to the constraint base. Try to directly add constraints where possible to the constraint base, e.g., for default constraints to avoid iterating over the complete constraint base before reasoning. However, due to the prioritization of the constraint types and their required sequence, this is not always possible. One alternative, a numeric prioritization of the individual constraints would require sorting the constraint base, at the new parts not the left-over constraints to be re-evaluated from a previous reasoning steps. However, implicit sorting on insertion according to priorities could help here. \item Create/translate a \textbf{constraint in one step}, if required in compounds split into filling the variability mapping and then creating the constraints based on the actual mapping. \item Try to figure out whether a certain \textbf{constraint (type) is actually needed} for reasoning and avoid its translation/creation wherever feasible. \TBD{Can we move the decision about keeping a constraint from adding it to the constraint base before constraint creation. However, this requires changes/additional alternatives for different code parts.}. Thus, don't re-process or filter certain constraint types at the end (done in the initial version for default and derived type constraints), as this implies iterating multiple times over the (partial) constraint base and re-creating/throwing away constraint instances in memory. - \item \TBD{Avoid storing constraints that can be \textbf{processed immediately}, e.g., default constraints. However, if a default constraint fails, it must be added to the constraint basis for later possible re-evaluation if dependent values become available/right.} - \item For identifying whether constraints are already in the constraint base, use a \textbf{fast look-up structure} instead of an iteration over the constraint base. Although the initial implementation utilized here reference equality (faster than the equals method), the current lookup structure is significantly faster than the original approach trading off execution speed for (peek) memory. Here a lookup structure based on reference equality could further speed up reasoning, which, however, may in the end be slower than the built in collections due to JIT compilation and JVM optimization effects. + \item \TBD{Avoid storing constraints that can be \textbf{processed immediately}, e.g., default constraints without dependencies. However, if a default constraint fails, it must be added to the constraint basis for later possible re-evaluation if dependent values become available/right.} + \item For identifying whether constraints are already in the constraint base, use a \textbf{fast look-up structure} instead of an iteration over the constraint base. Although the initial implementation utilized here reference equality (faster than the equals method), the current lookup structure is significantly faster (approx. 600 ms on large models, at that time around 25\% of runtime) than the original approach trading off execution speed for (peek) memory. Here a lookup structure based on reference equality could further speed up reasoning, which, however, may in the end be slower than the built in collections due to JIT compilation and JVM optimization effects. \item Incremental reasoning using a \textbf{stored constraint base} may speed up reasoning but only achieves this through large memory allocations. Ensure initializing the model through default constraints so that the actual stored constraint base only contains really needed constraint types, i.e., no default constraints and, if possible, no constraints for which all depending variables are already frozen. \item \textbf{Reuse visitor instances} if applied more than once, in particular reasoners with more complex internal data structures such as maps or lists. This required some refactoring of the IVML model implementation. \item \textbf{Avoid temporary instances}, e.g., iterators, temporary constraint creation, temporary data structures wherever possible. One option replacing a collection structure is to define a functor for processing the elements and to create a reusable instance of that functor. If permitted by the Java environment settings (EASy often compiles against JDK 1.6), also a lambda-function instead of a heavy-weight functor class may be appropriated. \item \textbf{Avoid multipe variable substitutions} per constraint expressions, i.e., join variable substitutions wherever possible. Variable substitution copies the expression. Multiple copies throws away the last copied expression. + \item \textbf{Use instance pooling} if datastructures are temporarily used, e.g., variable accessors in expression evaluation or sets of compounds in reasoning (20-30 ms on larger models, at that time around 10\% of runtime). \end{itemize} + +There are still opportunities for further speeding up the reasoning operations. On an Intel core i7, the reasoner reaches around 15-43 constraint evaluations in average per millisecond - runtime vs. full reasoning on the latest QualiMasster test model, currently reasoning time includes translation and evaluation time \TBD{Sepearte timing}. This is already an improvement over the initial version, which operated at around 10 evaluations per millisecond in average (also with a higher number of constraint evaluations due to unneeded and uneffective constraints). The constraint evaluation time probably suffers from the immutable structured values in EASy-Producer, which are created for each assignment. Knowing that most of the assignments in this model are done for basic IVML datatypes, a fast track for setting integer, double, boolean and String values could increase the number of evaluations, but requires careful extension, as changing values shall only be allowed via decision variables, which take care of the current assignment state, e.g., \IVML{FROZEN}. \section{Evaluation}\label{sectEvaluation}