Repository navigation
WebStorm debugger is extremely slow to start w/ Node.js 5.0.0 #3875
Description
Activity
+1, confirmed here as well.
Is there reason to believe it's a node.js issue? IIRC, last time it was weak interaction between V8 and WebStorm.
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.
Anyone able to try this patch to see whether it fixes anything? https://codereview.chromium.org/1454673002/
@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.
@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.
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.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.
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,
JustinOn 2 Dec 2015, at 3:58 PM, Ali Ijaz Sheikh notifications@github.com wrote:
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.
—
Reply to this email directly or view it on GitHub.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)?
Reproduced — v5.1 is dramatically slow compare to v4.2.2.
Please note that someone is reporting this is also occurring with node-inspector.
@yangguo-chromium I applied https://codereview.chromium.org/1454673002/ patch to nodejs 5.x sources —doesn't fix the issue.
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
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?
@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.
+1 I have the same problem in both version 11 and EAM version 12
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 ?
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
@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).
if anyone can provide a concise test case rather than "startup is slow".
Please see https://youtrack.jetbrains.com/issue/WEB-19117#comment=27-1287695
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?
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).
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).@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
I'll close the issue.
@bnoordhuis Sorry for reminder, but it will be also cool to merge #4231 to eliminate v5 regression.
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.