Repository navigation
WebStorm debugger is extremely slow to start w/ Node.js 5.0.0 #3875
Description
Here we go again. Looks like our friend is back again with Node.js 5.0.0. Confirmed w/ WebStorm 11.0.1 + Node.js 5.0.0. Reported there: https://youtrack.jetbrains.com/issue/WEB-19117
@develar I'm opening that there too, it might caused by a new v8 stuff.
Activity
hilkeheremans commentedon Nov 17, 2015
+1, confirmed here as well.
bnoordhuis commentedon Nov 17, 2015
Is there reason to believe it's a node.js issue? IIRC, last time it was weak interaction between V8 and WebStorm.
develar commentedon Nov 17, 2015
I don't experience any problem during fixing https://youtrack.jetbrains.com/issue/WEB-18853 I will check again ASAP, but, may be, it is already fixed in the not yet published WebStorm 11.0.2.
hashseed commentedon Nov 17, 2015
Anyone able to try this patch to see whether it fixes anything? https://codereview.chromium.org/1454673002/
unbornchikken commentedon Nov 17, 2015
@bnoordhuis You're right, but people will experience this issue when use WebStorm to debug their Node.js 5.0.0 applications. So, I believe that it's better to track there as well, to prevent it arise in this list over and over again.
HowlingEverett commentedon Nov 25, 2015
@develar I'm running the Webstorm 11.0.2 EAP, which includes WEB-18853. It fixes the debugger not running at all, but I still have a 30s+ wait for the debugger to launch and connect when running Node 5.0.
HowlingEverett commentedon Dec 2, 2015
This appears to be a debugger issue, not Webstorm specific. I get a similar delayed startup time when loading
node-inspectorwith the same project.For context, I'm also transpiling using
require("babel-core/register), but disabling the babel compiler doesn't seem to have any effect, it's still slow.ofrobots commentedon Dec 2, 2015
It would be nice if there was a reduced test case that could be generated from these debugger startup paths. That would be useful in verifying issues like this.
HowlingEverett commentedon Dec 2, 2015
I'll try to put something together. I'm not sure how reduced it can be since the slowness of the startup time seems to be dependent on the number of modules loaded in the application code e.g. If I create a trivial application the debugger session starts instantly, but as you start loading modules the load time grows ... Something worse than linearly...
Cheers,
Justin
develar commentedon Dec 2, 2015
Problem for me — that I don't have complex NodeJS app to feel the difference. Can somebody send me (attach to https://youtrack.jetbrains.com/issue/WEB-19117 and set visibility "jetbrains-team") test project?
Is startup slow in case of sample express project ("Node.js Express App" template)?
develar commentedon Dec 2, 2015
Reproduced — v5.1 is dramatically slow compare to v4.2.2.
hilkeheremans commentedon Dec 2, 2015
Please note that someone is reporting this is also occurring with node-inspector.
nodejs/node-v0.x-archive#9125
develar commentedon Dec 2, 2015
@yangguo-chromium I applied https://codereview.chromium.org/1454673002/ patch to nodejs 5.x sources —doesn't fix the issue.
unbornchikken commentedon Dec 2, 2015
More on track: Visual Studio Code is not affected, the integrated debugger is fast as hell (it attaches its debugger in the same way that node-inspector does).
10 remaining items
hilkeheremans commentedon Feb 10, 2016
Nitpicking, but keep in mind that the @AlexDobeck is not a resolution but at most a temporarily workaround for those who are not transpiling. It will break sourcemap support in most cases, thus it isn't a real solution if you are still transpiling somehow (e.g. async/await fans).
Personally, we are working around this by keeping
js.debugger.v8.use.any.breakpointenabled and using a specific.babelrcpreset (which transpiles to node v4) and node v4 for dev purposes. Our unit and integration tests can then be run on node v5 as desired. Of course, this won't work if you're totally dependent on node v5.. With a little luck, chances are you don't really need v5 functionality explicitly, or, that for dev purposes, you can work around with some extra transpile sauce.But again, this remains an extremely annoying issue, it's very costly in terms of dev or tooling-time. Assuming this is a similar issue rooted in V8, I'm a bit puzzled as to how this kind of regression could take place. Could the next kind soul who submits a PR for this on V8 also accompany this with relevant tests?
develar commentedon Feb 10, 2016
@hilkeheremans Well, we have made some changes to speed up — #4231 is not a real fix, but helps a bit (only V8 can fix this regression again (it was fixed some time ago, but broken again))), but 2 months passed and it is not yet merged.
zerocooljs commentedon Feb 24, 2016
+1 I have the same problem in both version 11 and EAM version 12
develar commentedon Feb 25, 2016
Well... If V8 doesn't want to fix it... We can implement another solution to not rely on V8. But this solution will be not generic. So I ask you — please send me (you can attach it to the https://youtrack.jetbrains.com/issue/WEB-19117 and set visibility to "idea-developers") test project where issue is reproducible.
Also, anyone is interested to try custom build with merged #4231 ?
hashseed commentedon Feb 26, 2016
Hi,
it's not that V8 is not willing to fix this rather than having no test case to go by. I suspect that this issue happens because Webstorm sets a lot of break points at start up, but have not gotten any confirmation so far.
Without a test case there is no way for me to fix this other than trying something, then ask and wait for feedback, which happened once in this thread already. The turn-around time sucks. A test case would also catch future regressions.
Besides that, V8 is currently moving towards using an interpreter for debugging. I expect this problem to go away once we do the switch, because recompiling is then no longer necessary.
So I'd be very grateful if anyone can provide a concise test case rather than "startup is slow". Thanks.
Yang
develar commentedon Feb 26, 2016
@hashseed Please see #3875 (comment) I think, it is the same regression again — any breakpoint. Not "because Webstorm sets a lot of break points at start up", but only because Webstorm sets any breakpoint (it is not a new functionality, since 2013).
Please see https://youtrack.jetbrains.com/issue/WEB-19117#comment=27-1287695
hashseed commentedon Feb 26, 2016
I actually think it might be a new regression due to a new cause. The old regression site did not change.
I'm not familiar with the nodejs debugging workflow, and don't use Webstorm at all. Would it be very difficult to create a standalone test case that runs on d8?
csvan commentedon Feb 28, 2016
Confirming in WS 11.0.3. Running on a 6700K CPU still takes about 10-15 seconds to start the app and reach first breakpoint (a plain run of the app has a bootstrap time of about 800ms).
ofrobots commentedon Feb 29, 2016
I am not sure what Node.js can do about this issue given that there is no test case (without external dependencies). 'WebStorm is slow' is not a test-case.
I think this bug belongs on the WebStorm repository. If you think this is a problem in Node.js, please provide a Node.js test-case without external dependencies. If you think this is a problem in V8, please open a bug against V8 (be prepared to provide a test-case that works on
d8without external dependencies).csvan commentedon Feb 29, 2016
@ofrobots is right, this is most likely an issue with node-inspector (which WS uses by default, to the best of my knowledge). See e.g. node-inspector/node-inspector#820
bnoordhuis commentedon Feb 29, 2016
I'll close the issue.
develar commentedon Mar 1, 2016
@bnoordhuis Sorry for reminder, but it will be also cool to merge #4231 to eliminate v5 regression.