Hi JerryBian,
We looked at your code and ran some tests; here's what we found.
Given the usage pattern you described, we recommend that you create and dispose engine instances as necessary. However, if the overhead of doing so impacts your server's scalability, you might consider a different strategy, such as engine instance pooling.
If you're using a single
The next version should be out shortly, hopefully by the end of this week or early next week. However, we don't release binaries, so you'll have to build it or acquire binaries elsewhere.
Good luck!
We looked at your code and ran some tests; here's what we found.
- You're using an old ClearScript version. Several issues related to memory usage have been fixed recently.
- There doesn't appear to be a memory leak in the latest ClearScript code. That is, all host objects released by V8's garbage collector are eventually claimed by the CLR garbage collector.
-
However, the current implementation of
V8ScriptEngine.CollectGarbage(true)is not exhaustive. Contrary to its documentation, the underlying V8 API defers cleanup in many cases. This is a problem in general, but it's particularly devastating when the unclaimed V8 objects are actually proxies to very large host objects. This issue may account for what you're seeing in dotMemory.
V8ScriptEngine.CollectGarbage(true).
Use global ScriptEngine instance or create one each time in our scenario?
Given the usage pattern you described, we recommend that you create and dispose engine instances as necessary. However, if the overhead of doing so impacts your server's scalability, you might consider a different strategy, such as engine instance pooling.
For example, if all the input scripts are same, ClearScript will cache the only one copy in memory to increase performance or cache every scripts? Do we need to cache it by ourselves?
If you're using a single
V8ScriptEngine instance to execute a given script repeatedly, you could gain a significant performance boost by compiling the script via V8ScriptEngine.Compile(). Another possibility might be to invoke script functions that are already stored within the engine. The idea is to avoid the script parser if possible.
What's the next release plan, we don't want to compile source code by ourselves?
The next version should be out shortly, hopefully by the end of this week or early next week. However, we don't release binaries, so you'll have to build it or acquire binaries elsewhere.
Good luck!