Next: , Previous: , Up: Expression Evaluator   [Index]

3.20 Optimizing Expressions

Expression optimization may (well, it should) reduce the evaluation time and the storage and evaluation memory requirements. However, since the optimization logic is not fast when compared with the evaluation logic, optimizing expression is usually pointless for one time evaluations.

The expression evaluator can performed a few simple expression optimizations, such as constant subexpression elimination, identity (or neutral) element elimination for operations defining one (such as addition and multiplication), etc.

Most optimizations are generic, i.e. the optimizer does not have built-in knowledge of function and operator properties and is instead deriving the possible optimizations from the function and operator definitions.

See Optimizing Prefix Unary Operators.

See Optimizing Infix Binary Operators.

Expression can be optimized through the x1f4_line_expression and x1f4_rule_expression functions.

See x1f4_line_expression.

See x1f4_rule_expression.

No side effects operators (X1f4_LEFT_XSET marked) and no application indicated as having side effects (X1f4_KEEP_CALL marked) functions and operators are optimized away.

See Binary Operator Flags.

See Operator And Function Flags.

The optimizer does not expect void functions to not have side effects, hence attempts to optimize expression referring void functions not being indicated as having side effects (X1f4_KEEP_CALL marked) should only be considered as alternative to


Optimizing expressions is in effect partial evaluation and thus all the evaluation requirements and prerequisites apply for optimizing as well. There are no requirements made by the expression evaluator, but there may be some coming from the function, operator, type definitions, etc (e.g. if a function requires a special context available for execution, it will also require it for optimization).

See Optimizing Expressions And Error Reporting.

Next: , Previous: , Up: Expression Evaluator   [Index]