* perf(javascript): trim per-evaluation work in the JavaScript evaluator
A Jint engine is built for every expression evaluation, so anything done during
setup is paid for on every evaluation. Four pieces of that work are avoidable:
* The three `IObjectConverter` implementations are stateless but were allocated
fresh for every engine. They are now shared static instances.
* Every prepared-script cache lookup — including hits — computed a SHA-256 hash
of the expression text, base64-encoded it and concatenated a prefix, purely to
build the cache key. Using a dedicated key type instead keeps the entries
distinct from other users of the shared cache while letting the expression
itself be the key, so a hit is a dictionary lookup. Looking the entry up
directly rather than through `GetOrCreate` also keeps the factory closure off
the hit path.
* `ObjectConverterHelper.ConvertToJsObject` built an explicit `PropertyDescriptor`
per property and called `DefineOwnProperty`. `CreateDataProperty` is public,
produces exactly the same writable/enumerable/configurable descriptor, and is
the engine's fast path for it.
* The variable write-back resolved the workflow input names — walking the whole
activity execution context ancestor chain — before checking whether there was
anything to write back. Only variables the expression actually referenced are
copied into the engine, so for the common case of an expression that never
mentions `variables.` the container is empty and all of that work is wasted.
The input names are also now looked up through a set rather than a list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0179sA2T7HuRfRfSc2JirFik
* test(javascript): pin the parse-failure test to the same exception every time
Calling `ThrowsAnyAsync<Exception>` twice only proved that both evaluations threw
something, which is exactly the assertion a poisoned cache would still satisfy:
had the failed preparation left a null or half-built entry behind, the second
evaluation would have failed too, just with a different exception. The test now
captures both exceptions and asserts they are the same type with the same
message, so "keeps reporting the same parse failure" is what is actually checked.
The message is stable to compare: it is `Could not prepare script: Unexpected end
of input (1:9)`, and since both evaluations run the identical script literal the
position is identical as well. No file or path detail is involved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0179sA2T7HuRfRfSc2JirFik
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
