This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "CPU Profiling" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Jon Kuperman: So this one, I'm gonna kind of just do together, cuz it's tiny and probably doesn't merit its own full exercise, but it's kind of cool just that in multiple ways, Chrome DevTools can help you really get a feel for how long everything takes to execute and they just added a brand new UI for it, which I think is really nice.
[00:00:24] So there's two ways to measure timing the kinda old way is using the console.time API, which is pretty cool. So you do like console.time and you pass in a unique string, like my edition function or something like that. And then at the end of it, you do console.time end and pass in the same string and it tells you how long it took between those things, but the new cool way built in the Chrome DevTools, let's go over here to this timing thing.
[00:00:49] I just got a bunch of code running, it doesn't do anything important. I'm not very creative. But basically, what you can do is you can come back in here and this is going to be our first time on the profiles page. So basically again, like timeline kind of does everything.
[00:01:04] It does profiling. It does network requests. It does a lot of stuff, but it's also very overwhelming to look at. So when all you need is one thing, like all you need is the JavaScript CPU profile or all you need is the network. I prefer to use the individual tab just, so it's less cluttered.
[00:01:19] So I'm gonna record a CPU profile and then again, just like I've been doing, I'm just gonna refresh the page.
>> Speaker 2: You need to start first.
>> Jon Kuperman: I do need to start first. Yes, this is the this is the one that behaves differently from the others. Thank you.
[00:01:35] Like network timeline, all of those ones will trigger a start if you refresh. With this one, you actually have to start the CPU profile and then refresh your page. And you can let it go for a second, if you want and then stop your profile. As a general rule with both timeline and profiles, if you're doing them after the fact like not with a refresh.
[00:01:58] Just keep them short, so you don't get too much information, especially with complex applications like I always try to keep them to like under five seconds, probably like you wanna measure like 30 seconds of app, cuz it's gonna compile way too much information. So if you're like worried about performance on when you click a certain button, I would like record click a button and the recording right then.
[00:02:19] So basically, this gives us a pretty similar looking thing to what we saw on timeline. It's just got its own view here. So it's like how long each thing took, the total time, everything like that. So, we can start looking at self-time. And again, we're gonna see all of these libraries, which is like not really what we wanna be checking out.
[00:02:37] So if we wanted to check out, for example, I have this timing.js file and I thought it would be fun to see a bunch of different functions. What's slow? What's fast? What takes a long time? We can just do a File > Find, like Ctrl+F or Cmd+F and look for my timing.js file.
[00:02:52] It's like way down here, but then you can click into it from the profiles page and it takes you to a sources page, except it has this cruel extra sidebar here, which tells you by each function how long it took to execute. So, I think this is really cool.
[00:03:09] This is also us kind of, so it's a micro optimization, but it's kind of surprising. Sometimes where you'll see certain operations, certain functions that are like really taking a lot of time, but I would only do it if you've kind of already proven that there's a JavaScript CPU problem.
[00:03:24] But anyway, I just thought that this was like cool. So basically, I've got functions that are like creating elements and appending them to the DOM and they're really fast and then this one here is actually the slowest one and it's actually just iteration over in array. I just kind of thought was interesting, it's like actually way, way faster.
[00:03:43] I mean, everybody always talks about the DOM being slow. It's actually way, way faster to create elements and append them and than it is to use the JavaScript for each over an array. You could also just do things like, if you cared about performance stuff, you could try a couple of different approaches like is a map faster than a for each faster than a for loop, but those three and refresh the page and just right here see how long they took to execute.
[00:04:03] I think it's kind of cool. It's basically like trying to think of whatever the website is that lets you compared to I was a performance that people use. Jasper, if it's kind of a Jasper built right into your DevTools which is kind of neat. So yeah, so basically, the longest operation out of all the stuff that I was doing was just iterating through an array of devs.
[00:04:25] So that was interesting, especially because there are only like five devs in that array. Yeah, so that's kind of timing another micro optimization, but pretty cool. Okay, cool.