Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Debugger is incredibly slow to start up #9125

Closed
fresheneesz opened this issue Jan 31, 2015 · 52 comments
Closed

Debugger is incredibly slow to start up #9125

fresheneesz opened this issue Jan 31, 2015 · 52 comments

Comments

@fresheneesz
Copy link

I'm working on a relatively large project in a vagrant virtual machine. Without the debugger, my servers take about 5 seconds to start up (start listening). With the debugger, this process bloats up to 2 minutes or so. The speed once its up is slower, but not nearly 20 times slower.

Its maddening to have to wait 2 minutes between debug cycles. When it takes 30 seconds to find and fix a change, the 2 minute wait is where most of my time goes. Is there any way to speed this up?

@askhogan
Copy link

Wow. I thought this was just me. I spent an hour today going through each require. I found mongoose was incredibly slow. I couldnt pin it down and eventually gave up an switched back to .10

I am using webstorm, but no fancy settings. It makes writing code so difficult.

@hankduan
Copy link

hankduan commented Mar 4, 2015

I saw something similar this week. Do you think it could be related to this? #9319

@misterdjules misterdjules added this to the 0.12.2 milestone Mar 25, 2015
@misterdjules
Copy link

@joyent/node-coreteam Adding this to the 0.12.2 with priority P-1 as it affects a lot of users of the remote debugger. See also nodejs/node#877.

@unbornchikken
Copy link

I have made some progress in investigation, please take a look at my comments there:

nodejs/node#877 (comment)
nodejs/node#877 (comment)

@pixelprodev
Copy link

0.12.2 released today and the issue still exists.. any word on this?

@misterdjules
Copy link

@ThePixelPro Yes, we made the decision to release v0.12.2 to make other important bug fixes available now. The issues that are still open in the 0.12.2 milestone will be moved to the 0.12.3 milestone, and this one specifically will be one of the top priorities for that milestone.

@misterdjules misterdjules modified the milestones: 0.12.3, 0.12.2 Apr 1, 2015
@pixelprodev
Copy link

Thanks for the update. I know I'm not the only one who's looking forward to this fix. Keep up the good work all.

@misterdjules
Copy link

@ThePixelPro Thank you for the support, it is very much appreciated 👍

@misterdjules
Copy link

@fresheneesz @askhogan @ThePixelPro @unbornchikken I haven't been able to reproduce the issue, do you have some detailed instructions with how I could reproduce that reliably? Does it happen with latest node v0.10 too?

Also, as @hankduan suggested, I have a hunch that it might be related to #17203. Would you mind building node with that change and let us know if it fixes your issue? That PR is specific to node v0.10, so if the problem is not present in node v0.10, that won't help. In that case let me know and I can provide you with a change that applies to node v0.12.

Thank you!

@unbornchikken
Copy link

Hello,

Please read through this thread carefully: nodejs/node#877

There you can find syntomps, logs, profiling data, repro cases, investigation results from the community, anything that required to identify and fix this isssue. I don't think that this is related to timers. This is realted to processing new JS files: nodejs/node#877 (comment)

I didn't tried node 0.10.37+. Has anyone result from this? If not, I'll try it later.

@misterdjules misterdjules modified the milestones: 0.12.3, 0.12.4 May 14, 2015
@tzaitsev
Copy link

I thought the goal was to get this into 0.12.3 re: "and this one specifically will be one of the top priorities for that milestone."

@pixelprodev
Copy link

@tzaitsev see the iojs link from @unbornchikken. (nodejs/node#877) toward the bottom they talk about a registry change made in webstorm that solves this issue. I'm not sure if this is a node core issue, but rather if this is simply something webstorm is doing to handle tooling with sourcemaps.

Personally, adding the change suggested has made starting the debugger almost instantaneous. I have not looked into it any further than that because it satisfied my particular need. Your mileage may vary.

@tzaitsev
Copy link

@ThePixelPro confirmed faster if you edit the registry on WebStorm and disable js.debugger.v8.use.any.breakpoint

Good call!

@alexander-tsig
Copy link

Where can I edit or disable on WebStorm of Mac?
js.debugger.v8.use.any.breakpoint

@wespen
Copy link

wespen commented May 21, 2015

I haven7t found that in Mac registry anywhere

@alexander-tsig
Copy link

So, isn't there any way to speed up loading of node debug on Mac's WebStorm?

@cjihrig cjihrig closed this as completed Oct 4, 2015
@davidje
Copy link

davidje commented Oct 26, 2015

Is it back? I still get this issue in 4.2.1 -- how can I confirm its the same exact issue? It only happens with Hapi or Mongo. Its double worse when I require both. When I commenting out Mongo and Hapi, it speeds it up. What are the steps to verify that I have the same issue? thanks

@o0x2a
Copy link

o0x2a commented Nov 16, 2015

I'm using latest version of webstorm 11.0.1 and node v5.0, and debugging node.js code is terribly slow. Vote up for a fix 👍

@Pat-rice
Copy link

Pat-rice commented Dec 1, 2015

@Code-guru I have node v5.1 and Webstorm 11.0.1 - Also incredibly slow.

@o0x2a
Copy link

o0x2a commented Dec 1, 2015

@Pat-rice use node-inspector instead, it's awesome. You may need to have Xcode/Visual Studio installed if you are mac or windows since it needs to compile some stuff when you install it. If you are on Ubuntu/Debian sudo apt-get install build-essentials may do the trick.

@HowlingEverett
Copy link

@Code-guru No luck, I'm afraid. This is a NodeJS 5.x issue, not a Webstorm issue. I am seeing similar delays (30+ seconds to attach to a debugging session) using the latest node-inspector with NodeJS 5.1.

@atom0s
Copy link

atom0s commented Jan 19, 2016

WebStorm v11.0.3 with Node.js v5.4.1, launching any of my projects in debug mode takes upwards to a minute for it to finally start. This issue is still definitely around.

Edit: This workaround does seem to fix the delay, but as others mentioned it has issues with debugging certain things then:
http://stackoverflow.com/a/31055505/1080150

@amcsi
Copy link

amcsi commented Jan 25, 2016

I'm getting this issue too.

/usr/bin/node --debug-brk=33810 --nolazy --harmony dist/server.js
Debugger listening on port 33810
Example app listening at http://:::8080

It takes 12 seconds to get from the second output row to the third.

@indutny
Copy link
Member

indutny commented Jan 25, 2016

@amcsi this is quite expected, I guess. Why are you using nolazy?

@amcsi
Copy link

amcsi commented Jan 25, 2016

@indutny WebStorm is adding that bit. The same Debug run that adds --debug-brk with a random number.
I'm happy to accept tips on how to disable the lolazy bit (couldn't figure that out yet), although I heard that I need that to properly debug async.

@develar
Copy link

develar commented Jan 26, 2016

@indutny V8 in lazy mode cannot debug column-based (e.g. lambdas) correctly — https://bugs.chromium.org/p/v8/issues/detail?id=2825
And, as you maybe remember, disabling lazy mode doesn't help — nodejs/node#877 (comment)

@XavierGeerinck
Copy link

Still having this issue too

@itai-codefresh
Copy link

also me

@wpoch
Copy link

wpoch commented Mar 11, 2016

I'm also having this issue with /Users/wp/.nvm/versions/node/v5.7.0/bin/node --debug-brk=52887 --nolazy --debug

@anyong
Copy link

anyong commented Mar 14, 2016

How is this issue still open after a year? Can never debug my apps properly as they take so long to start up... it's faster to just write a bunch of console.log's and restart the normal server. =/

@ChALkeR
Copy link
Member

ChALkeR commented Mar 15, 2016

@anyong It's not open, it's closed.

See nodejs/node#877 and nodejs/node#3875 (especially this one).

@emascarinas
Copy link

try adding:
--no-preload --hidden='node_modules'

@amcsi
Copy link

amcsi commented Apr 1, 2016

@emascarinas

"C:\f\PhpStorm 2016.1\bin\runnerw.exe" C:\p\nodejs\node.exe --debug-brk=50033 --harmony --no-preload --hidden=node_modules hot.js
C:\p\nodejs\node.exe: bad option: --no-preload
C:\p\nodejs\node.exe: bad option: --hidden=node_modules

Those don't appear to be valid node parameters

@develar
Copy link

develar commented Apr 1, 2016

@amcsi Nodejs 5 is slow for you, not 4, right? Fix (https://youtrack.jetbrains.com/issue/WEB-19117) will be available in the next PS update (2016.2).

@amcsi
Copy link

amcsi commented Apr 2, 2016

nodejs 5 yea

oh itll be fixed in the next IntelliJ version, cool!

@rorgonas
Copy link

rorgonas commented May 5, 2016

@emascarinas Thanks for your solution. It worked well.
Here is the complete e.g.
node-inspector --web-port 1337 --no-preload --hidden='node_modules'

@amcsi
Copy link

amcsi commented May 6, 2016

What is this node-inspector, and how is it going to connect to WebStorm?

@shaunwarman
Copy link

Start up seems fine in version 2016.1, but now I can't see any breakpoint data. I just see Collecting data... forever.

@develar
Copy link

develar commented May 10, 2016

@shaunwarman Node JS 6 supported, but IDEA with this fix is not yet released.

@shaunwarman
Copy link

Thanks @develar so I just need to drop node version to 5?

@develar
Copy link

develar commented May 10, 2016

@shaunwarman Yes. EAP release will be in a few days.

@shaunwarman
Copy link

shaunwarman commented May 27, 2016

Edit: After webstorm update everything works great with the debugger in node v6 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests