Hi Eric,
Sure. The biggest performance improvement for V8 users affects repeated invocation of host methods.
Let's say you've exposed the
Previously this required two expensive round trips across the native-managed boundary, but now host methods are cached as native JavaScript properties, so after the initial call, subsequent calls require only one round trip.
This caching mechanism is also used to speed up repeated access to host events and
Yes, that's the best general-purpose design for concurrent script execution via V8.
Cheers!
Can you elaborate any on "perfomance improvements for repeated execution"?
Sure. The biggest performance improvement for V8 users affects repeated invocation of host methods.
Let's say you've exposed the
Console type and are running a script that repeatedly calls Console.WriteLine(). Because methods in JavaScript are just function-valued properties, each call consists of two steps - fetching the "WriteLine" property and invoking the result.Previously this required two expensive round trips across the native-managed boundary, but now host methods are cached as native JavaScript properties, so after the initial call, subsequent calls require only one round trip.
This caching mechanism is also used to speed up repeated access to host events and
const/readonly fields (most significantly enum tokens).
I've been taking the approach of having a pool of runtimes and creating engines when needed via CreateScriptEngine from the runtime. I also compile and cache the scripts per runtime for reuse. Would that still be a recommended approach for a server-side implementation?
Yes, that's the best general-purpose design for concurrent script execution via V8.
Cheers!