Repository navigation
Slow vm.runInNewContext() #1631
Description
Activity
I am not really surprised given that iojs actually creates a real context whereas 0.10 was doing a weird fake-out. But anyway my best hope for fixing this (without profiling) is to get rid of the proxy global stuff; see #855 (comment). I want to at least try that anyway since it could simplify things a lot.
http://oserv.org/bugs/iojs/1631/ — callgrind output for
vm.runInNewContext('123')inside a loop.@domenic How is an additional 15ms acceptable? That's a cray amount of time to setup and tear down. It's not creating a new process, or even a new thread. Crap, I can bring my entire process up and down in a measly 60ms:
$ /usr/bin/time ./iojs -e '' 0.06user 0.00system 0:00.06elapsed 96%CPUGiven the overhead of a context (e.g. they're per-iframe in Blink) that seems totally acceptable as a startup cost. One extra frame (at 60fps) to load an iframe? Seems fine.
Are we a browser, or a server? Devs use
vmfor a lot of different things. Including to execute templates, of which they could be doing hundreds a second (well, not anymore). That type of reasoning would lead to the performance destruction of core.IMO people shouldn't be using vm for things they want to do more often than a typical web page would want to boot up an iframe. And that was a pretty crazy slippery-slope fallacy. But anyway, no use debating about this.
/cc @jeisinger who is the one working on making the snapshot-related parts of the startup faster. Maybe he can help give an overview. Since new VM contexts don't have any node code in them (right? no require or anything?) we should be able to benefit from the work pretty directly.
Right. No use debating because you have the answer. There's no fallacy. It's a fact.
vmhas gotten slower,Bufferwill soon be getting noticeably slower. And TBH your opinion doesn't matter. It's our job to make core as light weight as possible so we stay out of the way of our users.No, please don't put words in my mouth. No debating because it doesn't change what we can or can't do about this; we're going to make it faster if we can, obviously.
Mmmm... I think we are going in wrong direction with this. There is clearly some stuff that we need to figure out together, I suggest to do it in some different way ;)
Most of the time it's inside
v8::Context::New(env->isolate(), nullptr, object_template), called throughstatic void MakeContext→new ContextifyContext→CreateV8Context→Context::New.
From there, part of the stack that stays the same most of the time looks like this:[32] v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, bool) (244 x) [33] v8::internal::Genesis::CompileScriptCached(v8::internal::Isolate*, v8::internal::Vector<char const>, v8::internal::Handle<v8::internal::String>, v8::internal::SourceCodeCache*, v8::Extension*, v8::internal::Handle<v8::internal::Context>, bool) (268 x) [34] v8::internal::Genesis::CompileNative(v8::internal::Isolate*, v8::internal::Vector<char const>, v8::internal::Handle<v8::internal::String>) (246 x) [35] v8::internal::Genesis::InstallNatives() (12 x) [36] v8::internal::Genesis::Genesis(v8::internal::Isolate*, v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, v8::Handle<v8::ObjectTemplate>, v8::ExtensionConfiguration*) (12 x) [37] v8::internal::Bootstrapper::CreateEnvironment(v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, v8::Handle<v8::ObjectTemplate>, v8::ExtensionConfiguration*) (10 x) [38] v8::Context::New(v8::Isolate*, v8::ExtensionConfiguration*, v8::Handle<v8::ObjectTemplate>, v8::Handle<v8::Value>) (10 x) [39] node::ContextifyContext::MakeContext(v8::FunctionCallbackInfo<v8::Value> const&) (10 x)Here's a flame graph: https://cloudup.com/i-ZNuRsJu6i
Code that generated that flame graph:var vm = require('vm'); for (var i = 0; i < 1e3; i++) vm.runInNewContext('42');
- 36%
v8::internal::Parser::Parse() - 32%
Builtin:JSEntryTrampoline
Not sure what these two are doing, but they're taking up a significant amount of time.
- 36%
So the fact that you fall run into InstallNatives at all means that io.js doesn't use a context snapshot. Is there any specific reason you don't use that one?
vm.runInNewContextis not necessary for reproducing this,vm.createContextis also slow.
Apart from being slow, those contexts consume all the available memory. I am not sure if this has to go in a separate issue, so I'll mention it here for now.- Stale contexts can be destroyed only by full gc runs.
- Each full gc run (even manually triggered by
gc()) does not remove all the stale contexts but only a part of them (about 40-60%). - Automatic full gc runs are not frequent enough to keep the memory low, and rss goes up to 1.4 GiB (heapUsed to 880 MiB).
Each context consumes about 0.8 MiB.
Testcase:
var vm = require('vm'); var count = 0; function foo() { count++; var x = {}; vm.createContext(x); setTimeout(foo, 0); } foo(); /* /// Manual gc calls limit the heapUsed depending on the frequency of garbage collections function collect() { console.log(count + '? ' + JSON.stringify(process.memoryUsage())); gc(); console.log(count + ': ' + JSON.stringify(process.memoryUsage())); setTimeout(collect, 10000); } collect(); */ var gcs = new (require('gc-stats'))(); gcs.on('stats', function (stats) { console.log(count + ': [' + stats.gctype + '] ' + JSON.stringify(process.memoryUsage())); });
On the irc @bnoordhuis and @domenic mentioned something about not calling
ContextDisposedNotification()insrc/node_contextify.cc.9 remaining items
yes, you'll get a fresh global seed at startup, and every v8::Context gets it's own seed.
@bnoordhuis so, thoughts on re-enabling snapshots?
@trevnorris I think it should be safe.
- added a commit that references this issue
on May 8, 2015 @domenic apologizes for the rant. i'm peeved that buffer performance will be suffering, but it had nothing to do w/ what's going on with vm slowness. re-enabling snapshots have made everything much faster again.
This should be fixed by 36cdc7c.
- added a commit that references this issue
on May 19, 2015 Hi guys, I know this issue was closed, but context creation seems to be slow again. I'm using a node executable compiled with v8_use_snapshot = 1. Any advice?
cc @domenic