WebStorm debugger is extremely slow to start w/ Node.js 5.0.0

[unbornchikken]

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.

[hilkeheremans]

+1, confirmed here as well.

[bnoordhuis]

Is there reason to believe it's a node.js issue? IIRC, last time it was weak interaction between V8 and WebStorm.

[develar]

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]

Anyone able to try this patch to see whether it fixes anything? https://codereview.chromium.org/1454673002/

[unbornchikken]

@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]

@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]

This appears to be a debugger issue, not Webstorm specific. I get a similar delayed startup time when loading node-inspector with 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]

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]

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

On 2 Dec 2015, at 3:58 PM, Ali Ijaz Sheikh [email protected] 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.

[develar]

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]

Reproduced — v5.1 is dramatically slow compare to v4.2.2.

[hilkeheremans]

Please note that someone is reporting this is also occurring with node-inspector.

nodejs/node-v0.x-archive#9125

[develar]

@yangguo-chromium I applied https://codereview.chromium.org/1454673002/ patch to nodejs 5.x sources —doesn't fix the issue.

[unbornchikken]

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).

[christeiro]

Not sure if it helps anybody, but for me it worked when trying to debug node application through WebStorm. https://www.linangran.com/?p=569

[develar]

@christeiro Don't forget — if you "Uncheck ‘js.debugger.v8.use.any.breakpoint’.", you cannot debug sourcemap backed scripts anymore. But – since WebStorm 11.0.2 js.debugger.v8.use.any.breakpoint doesn't slowdown debug anymore in node 4.x (only 4.x). I really hope that in the next 5.x release my pull request will be merged — #4231 (thanks to @yangguo-chromium, change in the V8 master already).

[trmjoa]

Are there ANY other workaround for this issue other than js.debugger.v8.use.any.breakpoint? (Which as pointed out makes you unable to debug sourcemapped files) This is quite a serious issue for anyone doing development using the 5.x version. 45sec++ to start a debugging session isn't a very effective working environment

[hashseed]

Just trying to understand the problem: does WebStorm set many break points upon startup?

[develar]

@yangguo-chromium Yes, all breakpoints + any-breakpoint to debug sourcemap-backed script. But issue is reproduced also if only one breakpoint exists (any-breakpoint).

In my case I don't see any notable difference for simple applications, but if want to debug gulp scripts... it is really slow compared to nodejs v4.

[develar]

BTW, last time (#877) it was V8 issue, but not WebStorm (we didn't add anything new since then). My fix (#4231) doesn't help a lot.

[domosapien]

Using WebStorm 11 and node 5.4.1, I can't even get the debugger to work. It will connect, then when it gets to the breakpoint node will break but webstorm will never pick up that node is waiting for it.

[antanas-arvasevicius]

tested on node 5.5.0 + phpstorm 10.0.3 debugging is slow as hell too.

[makahn64]

Trainwreck for me. By the time my main app starts, it times out due to internal watchdogs. WTF?

[AlexDobeck]

Resolved for me by disabling the js.debugger.v8.use.any.breakpoint option in the Registry again as detailed in:
nodejs/node-v0.x-archive#9125

However, does have compatibility issues with certain breakpoints.

[hilkeheremans]

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 .babelrc preset (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]

@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]

+1 I have the same problem in both version 11 and EAM version 12

[develar]

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]

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]

@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

[hashseed]

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]

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]

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 d8 without external dependencies).

[csvan]

@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]

I'll close the issue.

[develar]

@bnoordhuis Sorry for reminder, but it will be also cool to merge #4231 to eliminate v5 regression.