Is an object pool suggested for speed performance?

[rushfrisby]

With some other javascript engines I found that instantiating the engine was very expensive and to combat this I created an object pool of engines. Would you suggest this approach for Jint as well or is creating an engine lightweight enough that it isn't needed?

[lahma]

There was some work done earlier to make engine instantiation faster, #625 . Engine will of course load features on demand so if you urilize all JS constructs the engine needs to initialize them lazily. Caching the parsed program helps too.

Sharing engine has the problem of old global state.
Probably depends on your use case and scripts.

[sebastienros]

@lahma what is your opinion about being able to mark an ObjectInstance immutable, such that we would not be able to change the builtin constructors, or mark pre-defined properties as not configurable. This way we could just re-initalize the lexical environments and reuse the engines. The main benefit would be that these built-in elements wouldn't have to be re-created.

It doesn't seem very hard to do, at least for the most obvious properties and constructor objects. Also it should be easy to cover everything as it would mean anything that has a property name currently in the engine code.

Forgive me if that's something I have already asked somewhere else ;)

[lahma]

I'm not against the idea, just a bit afraid of the complexity that might be involved with this freezing. I don't know if there's a cut-off point where we could declare engine fast to create and that wouldn't matter too much?

My gut feeling is that engine creation is now quite fast, but initializing the state into engine is the problem. Say that you want to include couple MB of your support scripts - most of the time will be spent parsing and preparing.

So might the actual requirement be to be able to inject start state faster into engine? Or if you mean these startup scripts as built-in elements then this would rhyme with what you expressed.

This is also somewhat related to #665 , #491 and #673

Of course we can always try to make engine creation even faster 🙂

And I want to end with a JS rant when I was thinking about inlining some known functions for performance:

> Math.max(1, 2)
< 2
> Math.max = null
< null
> Math.max(1, 2)
< VM1473:1 Uncaught TypeError: Math.max is not a function
<   at <anonymous>:1:6

This is why we can't have nice things 😠

[sebastienros]

I can see these two levels of reusability:

• The first one being about what I suggested so that we can reuse the engine instances and more importantly the existing constructor instances.
• The second one would be being able to take a snapshot of a state and restore it. This would prevent the execution of a script to reach a specific state, and internally we would clone this state of the engine.

Maybe the second option is also the way to implement option 1. Though freezing a state (default engine state) is even faster for perf than having to clone a snapshot (allocations).

[sebastienros]

But yeah, option 1 means we would disallow things like Math.max = null

[lahma]

@rushfrisby I'm working on PR #789 , you might want to follow that development and please chime in if it's missing something.

[ChrML]

Immutables is a nice solution to this. Keep a shared Math instance until you change it, then it becomes a new instance dedicated for that engine.