-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow vm.runInNewContext()
#1631
Comments
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 |
@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:
|
Given 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 |
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. |
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
|
Here's a flame graph: https://cloudup.com/i-ZNuRsJu6i var vm = require('vm');
for (var i = 0; i < 1e3; i++)
vm.runInNewContext('42');
Not sure what these two are doing, but they're taking up a significant amount of time. |
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? |
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 |
when the embedder no longer uses a context, this is usually a sign that a lot of previously live memory becomes garbage. V8 uses these notifications as one input to its GC heuristics. Another thing is that v8::Persistent<> handles only die after two full GCs:
as I mentioned before, if you want fast context creation, you should use a context snapshot. |
Ah, and some
|
@jeisinger Yes, enabling snapshots does help, but @indutny compared node 0.10 and iojs both without snapshotting and iojs has become 16 times slower. I think snapshots have been disabled due to possible collision DoS attacks. |
well, but the comparison is between a small shim, and executing almost a MB of script, so not sure what the point is? what kind of collision DoS attack would that be? Note that the deserializer puts in a fresh random seed on every run... |
Where is the MB of script in Take a look at this issue #528 |
@jeisinger Is the random seed you're talking about and the one @bnoordhuis mentions here the same? #528 (comment) |
@trevnorris that seed is independent of the snapshot and should change every startup if you provide a entropy source via v8::V8::SetEntropySource() the per-context random seed is generated here: https://code.google.com/p/chromium/codesearch#chromium/src/v8/src/bootstrapper.cc&rcl=1431042794&l=2942 - every context gets a fresh one based on the same RNG that heap uses (which in turn relies on the embedder providing an entropy source) |
@mathiask88 runInNewContext() invokes v8::Context::New in io.js and that runs all the .js files in v8/src (and some..) |
@jeisinger Thanks for explaining. |
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. |
@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. |
Also re-enable use of snapshots for armv6. Fixes: nodejs#1631
Also re-enable use of snapshots for armv6. Fixes: nodejs#1631
Also re-enable use of snapshots for armv6. Fixes: nodejs#1631
Also re-enable use of snapshots for armv6. Fixes: nodejs#1631
Snapshots had been previously disabled because of a security vunerability. This has been fixed (ref: #1631 (comment)) Also, re-enable snapshots for ARMv6 builds. There were previous build issues that have been fixed. Fixes: #1631 Reviewed-By: Ben Noordhuis <[email protected]>
Snapshots had been previously disabled because of a security vunerability. This has been fixed (ref: #1631 (comment)) Also, re-enable snapshots for ARMv6 builds. There were previous build issues that have been fixed. Fixes: #1631 PR-URL: #1663 Reviewed-By: Ben Noordhuis <[email protected]>
This should be fixed by 36cdc7c. |
Snapshots had been previously disabled because of a security vunerability. This has been fixed (ref: nodejs#1631 (comment)) Also, re-enable snapshots for ARMv6 builds. There were previous build issues that have been fixed. Fixes: nodejs#1631 PR-URL: nodejs#1663 Reviewed-By: Ben Noordhuis <[email protected]>
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
The text was updated successfully, but these errors were encountered: