Suddenly, WebStorm is going out to lunch while debugging

WebStorm 2017.3.4, Windows 10.  Starting today, before I upgraded from 2017.1.x to 2017.3.4, WebStorm started going out do lunch while debugging.  I made a video:

https://www.screencast.com/t/CFu6VxaHJ

At least, I think it's WebStorm.  Node.js is consuming all the CPU.  But only while debugging, not when just running outside the debugger.

I tried following instructions to take a CPU snapshot, but it caused WebStorm not to be able to launch.  Maybe I'll try again.

Eric

22 comments
Comment actions Permalink

node.js version is v8.9.1.

0
Comment actions Permalink

>At least, I think it's WebStorm.  Node.js is consuming all the CPU.

 

what process is consuming the cpu - node or Webstorm?

 

>I tried following instructions to take a CPU snapshot, but it caused WebStorm not to be able to launch.

 

what did you do exactly?

0
Comment actions Permalink

The process consuming the CPU is node:

What I did was I found this page:

https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems

and followed the instructions under Enabling Profiler Agent.  I did Help > Edit Custom VM Options and added the line to the 64-bit VM Options file.  But I just tried it again right now, and WebStorm is starting up fine, and I have the added choices on the Tools menu for profiling, so if that's what I need to do, I can do it.

Thanks,

Eric

0
Comment actions Permalink

I got a CPU snapshot and uploaded it via https://uploads.services.jetbrains.com/.  It's name is:

WS-173.4548.30_sasewh_17.02.2018_16.23.34.zip

Thanks, let me know what else I can do.

Eric

 

0
Comment actions Permalink

Could you please check if running the same command for debugging with --inspect-brk option and using Chrome DevTools causes the same slowdown?

0
Comment actions Permalink

Here is my WebStorm run configuration:

Does --inspect-brk go in the Node parameters: box?  Or somewhere else?

Eric

0
Comment actions Permalink

Putting it in the Node parameters: box seemed like the right thing to do, so I tried it, and it made no difference.  I'm not sure what the Chrome developer tools has to do with anything - I'm debugging in WebStorm, not the browser.  This happens with the developer tools closed.

Eric

0
Comment actions Permalink

No, I meant to try running it in a terminal, WebStorm is even better to be closed at this moment, just to check if the node process itself causes slowdown. Because I see no suspicious activity in the provided snapshot, only a lot of communication between node process and WebStorm.

0
Comment actions Permalink

Okay, bear with me, I have not used Chrome in this way before.

I went to a terminal window and ran "node --inspect-brk ./lib/server.js".  I jump over to Chrome and surf to "about://inspect".  I get the chrome://inspect/#devices window and it has a Target (v8.9.4) section with my ./lib/server.js in it.  There is also an Open dedicated DevTools for Node link.  I click that. 

I then get the Developer Tools - Node.js window, and there is my source code.  The debugger is paused.  I hit Resume.  My application initializes, and then I go to another browser tab and surf to my application's endpoint.  I can see console message from my application in the Chrome Developer Tools Console window.  In the Sources tab, Network subtab, I see all my source files listed.  I open one and set a breakpoint.  I navigate in the browser window and the breakpoint gets hit!  Very nice.

During this process, I'm not seeing *any* delays like I'm seeing in WebStorm.  It is running virtually full-speed.  So this is a nice workaround until we figure out what's going on with WebStorm.

Eric

0
Comment actions Permalink

Do you have an antivirus running?

0
Comment actions Permalink

Yes, Symantec Endpoint Protection.  I turned it off and tried again, but the performance did not improve.  Same symptoms.

0
Comment actions Permalink

I contacted my IT department.  They claim not to have done anything to my machine lately that would have slowed this operation down.  They had me update my BIOS.  No change in behavior.

Y'all have any more thoughts on this?

Eric

0
Comment actions Permalink

I set up VS Code to debug my node.js application as well.  Here again, no delays similar to what I'm seeing with WebStorm.  Looking at the Node.js process when debugging under VS Code, when I navigate in a way that would cause the node.js process under WebStorm to hit 20% CPU for 15, 20, 30 seconds, under VS Code, the node.js process maybe hits 5% or 6% for a second or two.

Eric

0
Comment actions Permalink

Could you please check if setting js.debugger.async.call.stack.depth to 0 in Registry (Help | Find Action | Registry...) makes things any better?

0
Comment actions Permalink

Setting js.debugger.async.call.stack.depth to 0 made no discernible difference. I tried setting it to 50 also, just to see if things got worse, but that didn't happen either.

Eric

0
Comment actions Permalink

Another wild guess: maybe removing -Djava.net.preferIPv4Stack=true from idea.vmoptions will help? If it doesn't, you may start the process from a terminal with --inspect argument and use "Attach to Node.js/Chrome" run configuration instead of "Node.js". 

0
Comment actions Permalink

Removing -Djava.net.preferIPv4Stack=true from idea.vmoptions was no help.  Using the "Attach to Node.js/Chrome" configuration had exactly the same performance characteristics as using the Node.js configuration.

I'm going to need more than wild guesses here, or I'm going to have to request refunds and move my team to Visual Studio Code.  VS Code is inferior in many respects to WebStorm, but it can debug Node.js applications without unexplained delays.

Thanks,

Eric

0
Comment actions Permalink

So, when you use "Attach to Node.js/Chrome" application works fine until you start debugging session, and starts consuming CPU after it? Could you please enable js.debugger.wip.log in Registry (Help - Find action - Registry...) by setting it to path to some temporary file like C:/tmp/wip.json? It will have communication log between IDE and node.js process with timestamps, so we'll see where delays are happening. If it's convenient for you, I suggest to open a support request and attach generated log there.

0
Comment actions Permalink

You're exactly right - the application works fine until I start the debugging session, and then node.js starts consuming CPU.  I will do the js.debugger.wip.log thing and open a support ticket.  Thanks!

0
Comment actions Permalink

Ticket opened (#1285639) and eric_hill_jmp_wip.json uploaded.  

I also tried moving the directory containing node.js to the front of my path instead of it being the very last thing in my path, but that didn't seem to help either.  If there is anything else path-wise that could make a difference, let me know.

0
Comment actions Permalink

WebStorm 2018.1 does *NOT* solve this problem.

Eric

0

Please sign in to leave a comment.