Re: [v8-users] Context creation overhead
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.
Maik Riechert schrieb am Mittwoch, 8. Dezember 2021 um 12:17:50 UTC:
> 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 schrieb am Montag, 6. Dezember 2021 um 14:29:24 UTC:
>
>> 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.
>>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/8f726281-31de-4845-9583-111282b49205n%40googlegroups.com.
Re: [v8-users] Context creation overhead
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 schrieb am Montag, 6. Dezember 2021 um 14:29:24 UTC: > 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. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/fce05ccc-aadb-4fec-b8a3-0478f03091fan%40googlegroups.com.
Re: [v8-users] Context creation overhead
On Mon, Nov 29, 2021 at 5:07 PM Maik Riechert 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. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKSzg3QfR0WoiqA5XKm9pUA25BkQvL19SxTP7BxT%2BEabNoeu2w%40mail.gmail.com.
[v8-users] Context creation overhead
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 -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/4e2d83c9-02bd-46fb-80d2-598e41cf7ca8n%40googlegroups.com.
