This project has moved and is read-only. For the latest updates, please go here.

Performance Implications of Multiple V8ScriptEngines tied to single V8Runtime.

Aug 14, 2015 at 8:07 PM
I am looking into V8 as a server side script engine and have some questions about the V8Runtime. Namely, what is the performance implications in having multiple script engines running concurrently from the same V8Runtime? Can two V8ScriptEngines execute compiled scripts on different threads concurrently (e.g. two ASP.NET web requests) without interfering with each other or blocking? Also what is the max number of engines that can be spawned from a single runtime? Is this simply limited by memory and cpu or is there some other internal limitations?

Any other insights you can provide on the the relationship between the runtime and the individual script engine is also much appreciated.

Aug 15, 2015 at 8:14 PM

V8 runtimes do not support concurrent access; in fact, they block it. Multiple threads may access different runtimes concurrently.

Within a runtime, multiple engines support data separation, not concurrency. Creating a new engine within an existing runtime is a relatively cheap way to get a pristine script execution environment.

We're not aware of any limits on the number of engines within a runtime, but runtimes themselves are quite expensive, especially in 32-bit processes. For multithreaded applications we recommend that runtimes be managed similarly to worker threads (and in similar quantities).

When you use the V8ScriptEngine constructor, you get a new engine within a private runtime. Use the V8Runtime constructor and V8Runtime.CreateScriptEngine() to set up shared runtimes.

Good luck, and please feel free to send any additional questions our way!