Repository navigation
io.js remote debuging is EXTREMELY slow compared to Node.js 0.10 #877
Description
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
Ndrou commentedon Feb 18, 2015
I have exactly the same problem... more than one minute to start my express project with --debug-brk in Webstorm :-(
Ndrou commentedon Feb 18, 2015
I tested many versions of node. The problem seems to appear from 0.11.15.
unbornchikken commentedon Feb 18, 2015
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).
bnoordhuis commentedon Feb 19, 2015
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.
unbornchikken commentedon Feb 19, 2015
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
bnoordhuis commentedon Feb 19, 2015
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.
unbornchikken commentedon Feb 19, 2015
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).
bajtos commentedon Feb 19, 2015
@unbornchikken can you try the following please?
Install
node-inspector@0.7and run it withDEBUG=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.
unbornchikken commentedon Feb 19, 2015
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.
unbornchikken commentedon Feb 19, 2015
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.
unbornchikken commentedon Feb 20, 2015
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:
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!
unbornchikken commentedon Feb 20, 2015
I've opened a discussing on JetBrains board too: https://devnet.jetbrains.com/thread/460705
develar commentedon Feb 20, 2015
I am developer of JetBrains JS debuggers.
WebStorm (IDEA) is slower (start) than node inspector due to two reasons:
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.
unbornchikken commentedon Feb 20, 2015
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?
develar commentedon Feb 20, 2015
@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.
124 remaining items
unbornchikken commentedon Nov 17, 2015
@hilkeheremans #3875
hilkeheremans commentedon Nov 17, 2015
@unbornchikken Right, sorry!
hashseed commentedon Nov 17, 2015
Can someone check whether this helps? https://codereview.chromium.org/1454673002/
test: use strict equality in regression test
test: use strict equality in regression test
test: use strict equality in regression test
test: use strict equality in regression test
test: use strict equality in regression test
test: use strict equality in regression test
test: rename test-regress-nodejsGH-877.js
test: rename test-regress-GH-877.js
test: rename test-regress-GH-877.js
test: rename test-regress-GH-877.js
test: rename test-regress-nodejsGH-877.js
test: rename test-regress-nodejsGH-877.js