FEEL expression parsing is repeated on every evaluateDecision call — no caching of parsed expressions in ScalaFeelEngine

[pe4enko]

Problem

ScalaFeelEngine.evaluateSimpleUnaryTests() and evaluateSimpleExpression() call feelEngine.evalUnaryTests(expression, context) / feelEngine.evalExpression(expression, context) on every invocation. These methods internally call parseUnaryTests() / parseExpression() each time, which includes:

1. Full fastparse grammar parsing of the FEEL expression (recursive descent, AST node allocation)
2. FeelParser.translateEscapes() — 8 calls to String.replaceAll(), each compiling a java.util.regex.Pattern from scratch (Pattern.compile → Pattern. → Pattern.expr → Pattern.sequence etc.)
3. ExpressionValidator.validateExpression() — full AST traversal for validation

Since DMN decision tables have a fixed set of FEEL expressions in their rules, this means the same expressions are parsed hundreds/thousands of times per second under load — for no reason.

Impact

CPU flamegraph from production shows FeelParser.parseUnaryTests → translateEscapes → String.replaceAll → Pattern.compile as a significant CPU hotspot. For a DMN table with 10 rules and 3 input columns, each evaluateDecision call triggers 30+ full FEEL parse cycles.

Root cause

ScalaFeelEngine (in camunda-engine-feel-scala) uses the deprecated FeelEngine.evalUnaryTests(String, Context) / evalExpression(String, Context) API which always parses. The FeelEngine class already exposes parseUnaryTests(), parseExpression() and eval(ParsedExpression, Context) separately, but
ScalaFeelEngine does not use them.

Additionally, FeelParser.translateEscapes() (https://github.com/camunda/feel-scala/blob/main/src/main/scala/org/camunda/feel/impl/parser/FeelParser.scala) uses String.replaceAll() which compiles regex on every call. These patterns are static and should be pre-compiled.

Suggested fix

Option A (ideal): Add a ConcurrentHashMap<String, ParsedExpression> cache inside ScalaFeelEngine. On evaluateSimpleUnaryTests / evaluateSimpleExpression:

• computeIfAbsent(expression, feelEngine::parseUnaryTests)
• Then call feelEngine.eval(parsedExpression, context) with the cached AST

Option B (minimal): Pre-compile the 8 regex patterns in FeelParser.translateEscapes() as static Pattern constants instead of using String.replaceAll().

Environment

• camunda-engine-dmn: 7.24.0
• feel-engine: 1.21.0

[saig0]

@pe4enko thank you for raising this problem. 👍

Option B (minimal): Pre-compile the 8 regex patterns in FeelParser.translateEscapes() as static Pattern constants instead of using String.replaceAll().

This is an interesting suggestion and independent of the script engine. We should try this. 👍

Option A (ideal): Add a ConcurrentHashMap<String, ParsedExpression> cache inside ScalaFeelEngine. On evaluateSimpleUnaryTests / evaluateSimpleExpression:

The script engine implements Compilable. You could call compile instead of eval to avoid the parsing on the DMN engine side. The compiled script can be evaluated.

@pe4enko could you use the compile method in the DMN engine and cache the expressions on this side?

[pe4enko]

Hi @saig0, thanks for the suggestion.

I agree that caching on the DMN engine side would be the cleaner design, since the parsed DMN model already has stable expression objects and the DMN engine already caches compiled artifacts for other languages.

However, after checking the code path, the relevant Camunda 7 integration lives in camunda/camunda-bpm-platform/engine-dmn, and that repository was archived on Nov 4, 2025, so it is now read-only. Because of that, I don't think the DMN-side change is actionable upstream anymore.

Given this constraint, the changes that still seem actionable in an active repository are FEEL-side improvements in feel-scala, for example the FeelParser.translateEscapes() regex precompilation.

For Camunda 7 users, a custom CachingFeelEngine remains a practical workaround for the repeated parsing in the current DMN evaluation path.

So from my perspective:

• DMN-side caching: I agree with the direction, but the relevant upstream repository is archived/read-only.
• FEEL-side optimization in feel-scala: still actionable here.

If you prefer, we can keep this issue focused on the parser-side optimization in feel-scala and treat the DMN-side caching idea as out of scope for this repository.

[saig0]

we can keep this issue focused on the parser-side optimization

Yes, please. 👍

For Camunda 7 users, a custom CachingFeelEngine remains a practical workaround for the repeated parsing in the current DMN evaluation path.

You could try to change the default expression language in the configuration. Instead of the FEEL integration, you could force the usage of the script engine by setting the language to feel-scala / feel-scala-unary-tests. I'm not sure if the C7 DMN engine can cache compiled scripts. However, you could give it a try. Alternatively, you could implement an engine plugin to configure or replace the FEEL or DMN engine.