Transcript from the "Node.js Debugging Solution" Lesson
>> Jon Kuperman: So I already have my thing running, if you wanted to follow along you would just kill your MPM start and you would run node --inspect server/index.js. Got that going, gotta come back here, open up the dev tools and I'm gonna mount these back to the bottom, open up the node dev tools which is whole another tab and then I would want to hit start and then refresh the page, and then hit stop.
[00:00:24] So a thing to always keep in mind when you're doing these profiles for CPU stuff, like why something took so long, is the shorter the better. If you do a ten second one a few things, you're gonna get a bunch of noise in there, but also it's gonna be hard to see anything because if the page took a second to load and you do a two second recording, that load will be big.
[00:00:44] You can see mine, right? It's big and easy to see. If you do a really long recording it's gonna be hard to zoom in and figure out where it is that you're looking for. So when you're doing the CP recording, you want to start it, do the thing as quickly as possible, and then stop it.
[00:00:57] So you're only capturing what you're interested in. Cool. So we can kind of zoom in over here. We kinda see this pattern here of the CPU profile. It's doing it's thing, doing it's thing and it's some really big stuff and then it finishes. So it kind of scrolling down into here, again, I just kind of wanna see what it is that's taking a really long time.
[00:01:16] And so kind of thing that I would look for here is I'm seeing that, let's zoom out a little bit. I'm seeing that everything kind of starts going here and then these are two, you can see here there's a division. There's two different parents, right, that trigger one right after another.
[00:01:34] This one's a lot smaller, so I'm gonna forget about it. This one's the biggest thing we have, right? It's total time is almost half a second. So why is it that this synonymous function takes so long? So oops, go back to the profile, so we're kinda tracing through, remember we don't care about every single function cuz a lot of these their self time is zero, it's just their children that are taking a long time.
[00:01:54] So again we'll go down to the last big one, right, the last long one that we see. We see this anonymous function with a self time, so we click on that and it takes us right into our app, right into our node code. So if you were to open my Mastering Chrome DevTools in your editor and go to the nodeserver.index.js, you'll see this exact file.
[00:02:11] And so it takes us right there right away. If we look back at the profile, we can get a little more information. So this is the long one, and what's it doing? It's calling fs.readFileSync a lot, that's what's taking so long. So we kinda go back over into the Sources tab, and we can see it's kind of doing this silly contrived thing.
[00:02:28] It's doing a loop and it's doing these readFileSyncs on a really long text file. Again, your app is gonna be a little bit more in depth to read and see what's going on. But we have a pretty easy way from a total backend node app that were unfamiliar with to targeting the function that's taking a really long time.
[00:02:45] So we could do something, there's tons of ways we could do this. This thing, since we're reading the same file each time, we could cache it out here. We could also make it asynchonous instead of a synchronous read. That's kind of getting into the Node.js world a little bit.
[00:02:57] But just so you know, if you're running any Node app, you can get right to the function that's your slowest. Any questions on the Node debugging?
>> Speaker 2: [INAUDIBLE]
>> Jon Kuperman: Yeah, this is what's so cool about it, yeah, absolutely, any of these nodes SLI apps you can just pipe through.
[00:03:14] So normally you would run no demand index subject so you can run node--inspect and then run no demanjs. JFs, so you could do stuff like that. And then yeah. It's really cool. There's a few, I've seen some really cool articles before where people profile node command line apps this way and it's really cool.
[00:03:32] You can see what Web next is doing or what Gulp's doing, or mode. It's really neat.
>> Speaker 2: Yeah, in the web pack course. It was Shawn Lark and he does that.
>> Jon Kuperman: That's awesome.
>> Speaker 2: And mine was [INAUDIBLE]
>> Jon Kuperman: Yeah, it's so cool.
>> Speaker 2: He'll walk through and step through your entire [INAUDIBLE] process.
>> Jon Kuperman: Right, what you normally see is a black box, right? What you normally see is, it feels like a binary.
>> Speaker 2: I ran this command, and then it kicks off 800 plugins.
>> Jon Kuperman: Absolutely, but you can start really seeing it. And then, you can go right to your source code that way.
[00:03:56] So it's really cool, only applicable if you do NodeJS. If you've got Ruby stuff, you'll have to find your own profiler for the other world. But if you do Node, you can use Dev Tools like that. It's just pretty cool.