Recycle workers after a certain number of usages

[Daniel15]

This should prevent memory usage from constantly increasing, and is similar to how Apache workers operate.

See reactjs/React.NET#78

[PeteDuncanson]

We've also read up that there are some tricks for making getting a new engine context spun up that is quicker than just using new V8Runtime();

https://clearscript.codeplex.com/discussions/461288

"We've run some tests, and your technique is much faster than instantiating V8ScriptEngine or invoking V8Runtime.CreateScriptEngine(); the latter is significantly faster than the former, but not nearly as fast as reusing the context. "

So might be something to be gained to switching to V8Runtime.CreateScriptEngine() for spinning up new V8 contexts from the current method, saves on the runtime initialisation I believe.

The custom method mentioned in the thread of clearing out global vars might work for us as we know which vars we used but might also be a way to use it given how fast they say it is. How ever they do its not 100% that you'll end up with a clear context but in the case of ReactJS we don't want a clear context, we what to keep React (and our bundle) in the global space for each engine. Would be interesting to hear your thoughts on that bit.

[PeteDuncanson]

The GetHeapInfo method on the V8Runtime might be handy for debugging or knowing when to recycle the engine?

[Daniel15]

So might be something to be gained to switching to V8Runtime.CreateScriptEngine() for spinning up new V8 contexts from the current method

I actually do something (use one engine and just create multiple contexts) with VroomJs, which is used for V8 support on Linux and Mac OS: https://github.com/reactjs/React.NET/blob/master/src/React.JavaScriptEngine.VroomJs/VroomJsEngine.cs#L70-L71. It might be worth modifying JavaScriptEngineSwitcher to do this (one engine, multiple contexts), or if they don't want to accept the changes into upstream then we could have a custom JavaScriptEngineSwitcher ClearScript engine that does things differently.

The custom method mentioned in the thread of clearing out global vars might work for us as we know which vars we used but might also be a way to use it given how fast they say it is.

That's basically the same thing that JSPool does though. JSPool is doing the same reuse of JavaScript engines, except it does not clear out any variables.

[PeteDuncanson]

That's basically the same thing that JSPool does though. JSPool is doing the same reuse of JavaScript engines, except it does not clear out any variables.

The difference in that last approach is we are keeping references to vars in the global space (I'm using some in my fork for passing the Router config around and the initial data). These appear to be growing in memory usage with every refresh. Clearing down the engines global vars (with the exception of React and React-Router) could allow GC to do its thing and release that memory while returning the engine to a clean "React ready" state without needing to spin up a new one if you recycled them for instance. Not sure if its a goer but nice to chew it over. While looking for performance gains I'm leaving no rock unturned :)

[Daniel15]

I'd suggest modifying JSPool to add the ability to run a callback when
engines are returned to the pool (similar to how the initialiser works),
then you can run whatever code you like when engines are returned. You
could then delete whatever variables you want to there.

Sent from my mobile.
On Feb 23, 2015 3:01 AM, "Pete Duncanson" [email protected] wrote:

That's basically the same thing that JSPool does though. JSPool is doing
the same reuse of JavaScript engines, except it does not clear out any
variables.

The difference in that last approach is we are keeping references to vars
in the global space (I'm using some in my fork for passing the Router
config around and the initial data). These appear to be growing in memory
usage with every refresh. Clearing down the engines global vars (with the
exception of React and React-Router) could allow GC to do its thing and
release that memory while returning the engine to a clean "React ready"
state without needing to spin up a new one if you recycled them for
instance. Not sure if its a goer but nice to chew it over. While looking
for performance gains I'm leaving no rock unturned :)

Reply to this email directly or view it on GitHub
#3 (comment).

[PeteDuncanson]

Great idea! +1