Context creation overhead

[Maik Riechert]

Hi all,

The CCF project (https://github.com/microsoft/CCF) is evaluating to use V8 as JavaScript engine (currently QuickJS) for handling HTTP requests. 

One of the requirements we have is that each request should get a fresh environment. In QuickJS, we simply create a new runtime for each request as it is very cheap. In V8 we re-use isolates but create a new context for each request. Is my understanding correct that using a new context is the only way to get an untouched JavaScript environment each time?

Some early performance tests indicate that we spend most of the time in creating new contexts. Looking at profiling data it seems that each time the (default) snapshot is decompressed and deserialized, and probably other initializations are done after that. It seems that decompressing and deserialization should only be done once and after that a memcpy would be enough?

Is there something obvious I'm missing?

Thanks for taking the time,

Maik

[Jakob Kummerow]

On Mon, Nov 29, 2021 at 5:07 PM Maik Riechert <maik.r...@arcor.de> wrote:

Hi all,

The CCF project (https://github.com/microsoft/CCF) is evaluating to use V8 as JavaScript engine (currently QuickJS) for handling HTTP requests. 

One of the requirements we have is that each request should get a fresh environment. In QuickJS, we simply create a new runtime for each request as it is very cheap. In V8 we re-use isolates but create a new context for each request. Is my understanding correct that using a new context is the only way to get an untouched JavaScript environment each time?

I believe so.

 

Some early performance tests indicate that we spend most of the time in creating new contexts. Looking at profiling data it seems that each time the (default) snapshot is decompressed and deserialized, and probably other initializations are done after that. It seems that decompressing and deserialization should only be done once and after that a memcpy would be enough?

Is there something obvious I'm missing?

You can turn off snapshot compression to see if that makes a difference. Add v8_enable_snapshot_compression = false to your GN args.

I don't have any other ideas how to speed up Context creation. From a browser's point of view, we consider snapshot-based Context creation "pretty fast", but it may well be that for a different environment (where presumably you have very many, very quick computations that require a fresh Context each) it's plausible that the relative overhead is much bigger.

[Maik Riechert]

Sorry for the late response, for some reason this ended up in spam...

On 29.11.2021 23:50, Jakob Kummerow wrote:

You can turn off snapshot compression to see if that makes a difference. Add v8_enable_snapshot_compression = false to your GN args.

Disabling snapshot compression helped a bit. As a test, I also disabled string rehashing. Now most of the overhead is deserialization. I attached a flamegraph, maybe that gives some insight.

[Maik Riechert]

I had another thought about re-using contexts. If there was a way to freeze the global object (make it and all its child objects read-only), would that be enough to guarantee a predictable state per request? I realize that this probably would break some libraries, but I'd like to explore it nevertheless. This would preclude caching any v8::Module objects (since they have state as well), but that would be fine.

[Maik Riechert]

I did some more experiments and it turns out that freezing all globals breaks quite a bit of code since the semantics for property assignment change. For example, the following pattern wouldn't work anymore if Error.prototype is frozen:

function MyError(e) {}
MyError.prototype = new Error
MyError.prototype.name = "MyError"; // ignored or TypeError if strict mode

or more simply:

var e = new Error;

e.name = "MyError"; // ignored or TypeError if strict mode

I guess object freezing can't be an after-thought and has to be part of the contract of an API, in this case the built-in API.