Support evaluating precompiled AST (evaluateAst)

[Zhreyu]

Hi,

We’re using cel-js in a system where CEL expressions are compiled and stored
as AST (serialized JSON) in a database.

Currently, Environment.evaluate() requires a source string and internally
re-parses it on every call. This prevents reuse of precompiled ASTs and leads
to repeated parsing overhead.

Would it be possible to expose an API like:

evaluateAst(ast, context)

This would allow:

• Reusing compiled expressions across requests
• Avoiding repeated parsing
• Better performance in high-frequency evaluation scenarios

Happy to contribute if this aligns with the project direction.

Thanks!

PS: we're aware of parse() for in-memory reuse. Our use case requires persisting the compiled AST to a database and reloading it in a different process/request without re-parsing. The current AST structure contains function references (#meta.evaluate) that aren't JSON-serializable, so we can't round-trip through storage.

[marcbachmann]

Not sure whether this is wise.
Transfering a large AST is slower than always evaluating it. A simple lru cache would be a better fit in most cases 😉

[Zhreyu]

Thanks for the response! To clarify, the LRU cache pattern works great for in-process reuse, and we're using that approach too.

The tricky bit for us is we're running in a serverless-ish setup where the process compiling the expression isn't the same one evaluating it later. So we compile at authoring time, stash it in the DB, then some random cold-start instance picks it up hours later. LRU doesn't really help there since the cache is always empty on first hit.

the blocker we hit is that the AST has those #meta.evaluate function refs that don't survive JSON round-tripping. If there was a way to get a "dead" serializable AST (or reconstruct it from one), that would unlock the whole flow for us

Let me know if this is something worth exploring, appreciate you taking the time!!

[marcbachmann]

Thanks for the answer. Before something like this would get implemented, I'd first benchmark the actual json parse performance and the benefit we could get (the AST can get quite larger than the string version).
Expression parsing might at the moment still be faster than any actual I/O operation.

Also, is this a theoretical issue or an actual issue you're observing in a production application?

Some details why passing a serialized AST is not supported:

• uint & int (bigint) don't have json serialization support
• macros are expanded during parse time, so another tree iteration could break performance benefits we currently have.

Another improvement we could do first:

• Internally, the checking of AST trees must happen once before every execution. With the current implementation we do that once per constructed AST if it wasn't checked before. But basically it iterates the tree twice for one-time execution.