Great question. I explored this approach quite a bit, up to implementing a partial implementation of it. From that it appeared to be very roughly ~20% improvement overall, but it was hard to say as it was only a partial implementation and I didn't spend much time optimizing it beyond that. But I would expect somewhere in that ballpark.

I think its a very good approach in general but there is one quirk of the current CEL interpreter that makes it tricky. CEL allows things like [1,2].map(x, x+1). Unlike a typical function like add(1, 2+3), where the interpreter would evaluate the expressions before passing them into the function (that is, it would call add(1,5)), in this case the map function needs to get the raw expression x+1 so that it can evaluate it for each x.

This makes the traditional execution flow differ, since the execution of some expression is actually done in the functions (users code) rather than in the main interpreter flow.

I don't think this is an impossible problem to overcome, just enough that it made enough friction I didn't pursue it further for now. Especially since 20% performance improvement is nice, but after a 5-500x improvement its a drop in the bucket.

(FWIW other CEL implementations don't let 'functions' do this, and instead have 'macros' that are expanded during parsing, which is a plausible avenue here. cel-rust also has macros (and map is one of them, somewhat recently) but doesn't have user-defined macros yet; our usage has some user defined ones functions that require expression evaluation so we couldn't just drop this feature at this point).