Skip to content

io.js remote debuging is EXTREMELY slow compared to Node.js 0.10 #877

Description

@unbornchikken

Hello,

If I run a debugging session in WebStorm or the recently fixed (node-inspector/node-inspector#563) node-inspector (--debug-brk), booting of the application takes forever. Even processing of the few require lines on top of my app.js file takes forever. I can se that io.js process is eating up a whole core of my i7 CPU. It takes almost two minutes to get the server started. In Node.js 0.10 this was around 7-10 seconds. I've tried Node.js 0.12. It's interesting because it's very slow too, but a slightly faster than what I'm experiencing in io.js.

Are there some parameters to speed thing out?

Activity

  1. Ndrou commented on Feb 18, 2015

    @Ndrou

    I have exactly the same problem... more than one minute to start my express project with --debug-brk in Webstorm :-(

  2. Ndrou commented on Feb 18, 2015

    @Ndrou

    I tested many versions of node. The problem seems to appear from 0.11.15.

  3. unbornchikken commented on Feb 18, 2015

    @unbornchikken
    Author

    Sadly this bug makes node-inspector kinda useless POS with io.js. I don't even know a sane method to debug my applications in io.js, I simply don't have hours to wait for a breakpoint get hit. Switched back to Node.js 0.10 :(

    I can confirm that this issue present with io.js 1.2 on Linux x64, Linux x86, Windows 8 x64 (and with Node.js 0.12 on those platforms).

  4. bnoordhuis commented on Feb 19, 2015

    @bnoordhuis
    Member

    I can't reproduce with the built-in debugger on a medium-sized application. What does the WebStorm debugger do that the built-in one doesn't?

    Also, /cc @bajtos.

  5. unbornchikken commented on Feb 19, 2015

    @unbornchikken
    Author

    It's using remote debugging exactly like node-inspector, it opens io.js with --debug-brk. This issue is not related to WebStorm it's related to remote debugging. I can reproduce this bug with node-inpector, which has an io.js compatible version in a PR there: node-inspector/node-inspector#563

  6. bnoordhuis commented on Feb 19, 2015

    @bnoordhuis
    Member

    That's why I cc'd @bajtos, he's the maintainer of node-inspector. It's still unclear to me why external debuggers are problematic when the built-in debugger seems to be working fine.

    EDIT: To be clear, the built-in debugger is a 'remote' debugger as well; it runs in a separate process.

  7. unbornchikken commented on Feb 19, 2015

    @unbornchikken
    Author

    I get it, sorry. I've just tested one of our medium sized express application with node-inspector and WebStorm on Linux (by using debug-brk and manual start). It was 7 seconds to get server started with Node.js 0.10 on both debuggers. It was 37 seconds to get server started on node-inpector. It was 43 seconds to get server started on WebStorm debugger (I think it's slower slightly because of the nolazy flag).

  8. bajtos commented on Feb 19, 2015

    @bajtos
    Contributor

    @unbornchikken can you try the following please?

    Install node-inspector@0.7 and run it with DEBUG=node-inspector:protocol:*. Save the logs for both 0.10 and 0.12. Then compare the logs and look for requests/responses that take unreasonable long time to complete in 0.12 compared to 0.10.

    You can also upload the logs as a gist, so that we can take a look too. Please don't paste them as a comment in this issue, because they are long and they would make the comment page difficult to read.

  9. unbornchikken commented on Feb 19, 2015

    @unbornchikken
    Author

    I've tried my best, but there was some issues. I was not able to log anything with Node.js 0.12, because it didn't honoured debug-brk, it started the application immediately. So I created logs with Node.js 0.10.30 + node-inspector@0.7, and with io.js 1.2 + node-inspector@node-inspector/node-inspector#563.

    It's uploaded the results along with shell scripts there: http://1drv.ms/1AX33g8

    This time Node.js 0.10 server startup time was slightly slower, maybe because it was debug mode enabled, but WebStorm started the server within 7 seconds in debug mode as a said before. io.js was the same as before.

  10. unbornchikken commented on Feb 19, 2015

    @unbornchikken
    Author

    Tomorrow I'm gonna make logs by using Fiddler when debugging my project in WebStorm. Its debugger consistently supports all versions of node and io.js, maybe we will figure out what's the cause of this better with it.

  11. unbornchikken commented on Feb 20, 2015

    @unbornchikken
    Author

    Ok, guys, there is the stuff. I have full pcap captures of Node.js 0.10.36 and io.js 1.2.0 debugging sessions. I've made it with RawCap, it shows a WebStorm debugging session from beginning to get a restify server started. I placed a breakpoint there.

    io.js: http://1drv.ms/1w4n04n
    Node.js 0.10.36: http://1drv.ms/1w4nyXW

    You can open them in Wireshark, and can filter to communication streams by using the following filter:

    tcp.stream eq 0 && tcp.len > 0

    The whole session length is:

    • node.js 0.10.36: 11 seconds
    • io.js 1.2.0: 78 secons

    This mean it takes 7x more time to get breakpoint hit in io.js! If this is not a bug, then what?

    I cannot se any notable difference between the communication (Follow TCP stream in Wireshark), in io.js it just slow.

    I'd appreciate if someone with deep v8 debugger knowledge could take a look at this, thanks!

  12. unbornchikken commented on Feb 20, 2015

    @unbornchikken
    Author

    I've opened a discussing on JetBrains board too: https://devnet.jetbrains.com/thread/460705

  13. develar commented on Feb 20, 2015

    @develar

    I am developer of JetBrains JS debuggers.

    WebStorm (IDEA) is slower (start) than node inspector due to two reasons:

    1. V8 debugger protocol is ugly (compare to WIP). So, we bootstrap our own implementation (using evaluate) on start. Yes, our protocol should be pulled to V8 (or node/io.js), but it works without problems.
    2. WebStorm loads global variables on start (it is required for live console). You can disable it — pass vm property: -Djs.debugger.load.global.variables.on.start=false

    I don't experience slow down on Mac OS X, but we have user report https://youtrack.jetbrains.com/issue/WEB-14539#comment=27-925591

    There is some difference between WebStorm 9 and WebStorm 10 (139 branch and 140), but in this area nothing was changed in the past 6 months.

  14. unbornchikken commented on Feb 20, 2015

    @unbornchikken
    Author

    Do you have any idea why does WebStorm debugger hit the same breakpoint in the same project much slower in io.js than in node 0.10?

  15. develar commented on Feb 20, 2015

    @develar

    @unbornchikken I have not yet looked closely, but we don't use v8 implementation of RPC "break" event, we use our own efficient implementation, so, the problem is not on the RPC level (and not due to some changes in this area in io.js), but in the V8 core itself.

    I cannot reproduce the problem: WebStorm 140, OS X, nodejs 0.12 or io.js 1.2.0 — start debug and stop on breakpoint are not slow.

  16. 124 remaining items

  17. unbornchikken commented on Nov 17, 2015

    @unbornchikken
    Author
  18. hilkeheremans commented on Nov 17, 2015

    @hilkeheremans

    @unbornchikken Right, sorry!

  19. hashseed commented on Nov 17, 2015

    @hashseed
    Member

    Can someone check whether this helps? https://codereview.chromium.org/1454673002/

  20. added a commit that references this issue on Mar 6, 2018
  21. added a commit that references this issue on Mar 8, 2018
  22. added a commit that references this issue on Mar 17, 2018
  23. added a commit that references this issue on Mar 20, 2018
  24. added a commit that references this issue on May 8, 2018
  25. added a commit that references this issue on Sep 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions