4

I'm using node v6.10.0 and trying to figure out why my --debug-brk is so incredibly slow. Without this flag (with just --inspect or --debug), it's almost instantaneous, though the debugger still takes forever to attach.

This one flag dramatically increases the load time. My project is taking 50s+ to start up when debugging is enabled.

Any ideas on how to start debugging this issue?

Edit: To be clear, it's happening across two computers and does NOT happen with Hello World.

Edit 2: More detail. I'm using es6. I used webstorm to log out what was going on and found that it was just taking forever to read all my modules? Perhaps that's what's going on?

Is there a way to speed this up? It's taking 34 seconds just to load all the require statements.

Edit 3: It's absolutely the files and require statements. I moved some of the require statements to only load after the database connection is established. The connection is established instantly, but the process hangs on moving forward after that (again for several, several seconds).

Is there any way to speed this up?

MattEnth
  • 843
  • 1
  • 7
  • 19
  • I've had that issue myself with node.js on my Raspberry Pi. I concluded that the problem for me was that the debugger was taking enough extra memory (on the relatively small memory Raspberry Pi) such that the OS was running out of physical memory and thus swapping to disk and that was the cause of my slowness. Don't know if you might have a similar cause, but something to consider. – jfriend00 Mar 14 '17 at 06:17
  • That's not it, sadly :-\ added more details to my OP. I think it's just file read/parse times. – MattEnth Mar 15 '17 at 01:14
  • Is it plain ES6 or transpiled ES6? Are there .map files being loaded by the debugger? It can't be only your `require()` statements if it loads just fine when you use different flags. The `require()` statements have to all happen either way. So, it has to be something else. – jfriend00 Mar 15 '17 at 05:22
  • Plain ES6. I've been talking to Webstorm support and added an export to js.debugger.v8.log. It just is taking forever to load all of the files. I think the issue is the number of files overall... There are ~500 files plus the node modules – MattEnth Mar 15 '17 at 18:43
  • How long do you expect it to take to load 500 files? It sounds like you are just disk bound. – jfriend00 Mar 15 '17 at 20:56
  • But why would it be different between just a regular nodejs application starting and --debug-brk? Or debug or --inspect? All of these are much faster, but --debug-brk is the only one that's slow – MattEnth Mar 15 '17 at 23:46
  • Are you using babel? If so, that's your culprit right there – mrBorna Mar 22 '17 at 21:05

1 Answers1

1

What do you mean by "load time"? Are you talking about time between opening the frontend (e.g. Chrome DevTools) and hitting the breakpoint on the first line of your script?

From your description it sounds like there's an issue with the socket connection being slow. Some things to check:

  1. If the URL your Node.js version outputs has localhost - replace it with 127.0.0.1. Some OSes use DNS to resolve this name and might fail to resolve it or to be slow.
  2. Do you have any issues with the network access? Particular Chrome DevTools version has to be downloaded for your node version, this might be slow.

This might be a bug in particular Node.js version (I cannot recall anything specific that might've caused this). What is puzzling is that it is app specific - when you run with --debug-brk or --inspect-brk no JS is executed until after the debug frontend is connected.

Please consider reporting this issue on Node.js bugtracker - feel free to CC me directly (add @eugeneo anywhere in the bug description)... Is there any chance I could see your code - e.g. is it on GitHub? Also - can you please try a newer Node version?

Eugene
  • 9,242
  • 2
  • 30
  • 29
  • Thanks for the help. I've posted the full log here to maybe illustrate the "load time" I'm talking about: http://c.opencritic.com/log.json . No issues with network access. I'm mostly trying to use the WebStorm built in tools, though the issue happens with just command line and Chrome. Once the debugger is attached, it's great, but it's just taking forever to attach. – MattEnth Mar 22 '17 at 15:24
  • Does not seem like there's much that can be done on the Node side. I also spoke with V8 developers - they say this performance is expected... The problem is that the application executes extraordinary number of scripts (V8 and V8 debug interfaces were designed for web applications that do not reference thousands of scripts). This is obviously something that will have to be addressed for Node.js - but there's no solution in sight at this point. – Eugene Mar 22 '17 at 22:36