Mastering Chrome Developer Tools v2 Chrome Task Manager & Snapshots

[00:00:00]
>> Jon Kuperman: Kind of back over here on the lessons page, we've got this memory leak section. So what we wanna do is this is a page that I made that has a memory leak on it. And we wanna see what tools that we have for catching memory leaks. So the first one, [LAUGH] is the only thing that I show that's actually not part of the developer tools, but it is part of Chrome which is really cool.

[00:00:18] So if you go to these three dots up in Chrome, and you go down to More Tools > Task Manager. I'm not sure how many of you knew, but Chrome has a task manager where it keeps track of each tab and its performance. And then by default, JavaScript memory won't be on there.

[00:00:34] So you'll want to right-click up at these headers and add JavaScript memory. And then it should show up. And then you'll wanna select this top-down view of JavaScript memory. And so what we can kind see here, I know it's small. Unfortunately, I can't zoom in, but as we see, we've got three tabs open, right?

[00:00:52] Really, I think two of them are from my slides. And the two of them from my slides with those Ss on them are stable, right? They're not moving cuz they use the memory they needed to use and now they're using it. But mine is mastering from DevTools is just going up and up and up and up.

[00:01:06] So that's one easy way to see. If your site's just sitting here and your JavaScript memory usage is going up, that's a really good way of knowing you have a memory leak. A way of visualizing it is if you open up DevTools, you can go ahead and pin this back to the bottom.

[00:01:19] And then you go to the Performance tab. Again, performance and memory kind of have a lot in common. The performance tab is the best one for spotting a memory leak. The memory tab is the best one for figuring out what it is that's what's going on. So with the Performance tab, we'll check this memory checkbox here.

[00:01:34] And remember in the last section I said when you're doing performance recordings for CPU, you make them as short as possible. When you're doing performance recordings from memory, you wanna do them longer, cuz you wanna see it over time. You're not looking at the CPU. So I'll hit it.

[00:01:48] I'll let it run for usually a couple of seconds. It doesn't need to run for a significant amount of time, but you do wanna see is this building over time as opposed to a one second. It might not see anything. So go ahead and stop that. I'm gonna move down the summary view.

[00:02:01] What I'm gonna do is at this time is I'm gonna move up the memory view
>> Jon Kuperman: I'll try to move these tools.
>> Jon Kuperman: And here we go, this is the jigsaw pattern that we don't wanna see, right? And so what we can see is what you normally want to see and actually I think there's some good examples, yeah, so this yellow, this event listener is a great example.

[00:02:25] So the page starts, and they start reasonably high, a decent amount of memory being used. And then they finish and a garbage collection happens here. We'll get into garbage collection in a second. And then they're done, right? Then yellow is back to this, just one. Whereas the blue, you see it kind of starts off its thing here.

[00:02:43] And it does clean and then it just starts growing and growing and growing and growing and we're not doing anything. This might be normal if it was calculating something, but for a page just to be sitting here, we shouldn't be seeing these jigsaws, right? And so this is always the shape that you want to watch for is this up and up and up jigsaw.

[00:03:00] A cool thing about this is that it tells you specifically what type of memory it is. So it breaks it into JavaScript memory, document memory nodes, like elements and event listeners. And it kind of breaks into those categories so at least you have some clue of where to start with it.

[00:03:14] So then the next thing you want to do, confirming you have a memory leak, which you do via the task manager and via the Performance tab, is you wanna go into the memory section. And basically they have these kind of three tools for analyzing memory, cuz now we're getting into, well, what's using that memory?

[00:03:29] What's going on here? The first one is a heap snapshot, so it just grabs the whole memory heap, everything that's being used, and it'll show it to you. [SOUND] Paused because of potential out of memory crash. My fault,
>> Jon Kuperman: Too much memory. Okay, cool. So the first one is it takes a heap snapshot, and these are really cool because they'll show you everything that's being used, so you can see what's using the most memory.

[00:03:54] But what's also really neat about them is you can take multiple and compare them to each other. So you can take one, give it a few seconds, take another one, compare them to each other, see what's changed. Beyond that, you can do these kind of allocations. And so these are really cool, these kind of allocations over time.

[00:04:10] It's basically the same as taking a bunch of heap snapshots, but you can start seeing, is the memory going up and up and up? Or is it going up and down, these different things. So an allocation will take a long amount of time, and then it'll just grab a few heaps as you go through there, basically.

[00:04:25] And so then this one is like on allocation sampling. So basically it's like, takes it over a long period of time, it'll take a bunch of different samples there. So this kind of breaks into a little bit of a hard to tell. Do you have a memory leak that's very obvious, like the one on the demo page that I have where in six seconds you see it just growing?

[00:04:45] Or do you have one that you suspect over a long period of time as you're using the app, in which case you can start the sampling and you go back to using your apps. So I've had apps before that people use throughout their whole day. Creatives will use to draw and save files, or whatever.

[00:04:58] It seems after about an hour of use, the site gets really slow. That's harder to debug, right? So we can do one of these samplings and we can just go back to using the site. As it gets slow we can end it, and then we can see what's going on.

[00:05:08] But for today's stuff we can just get away with just some heap snapshots, or we can do the allocation time line. So let me show what those look like. So from the lessons page I'll go to memory leaks, and then I'm going to click Heap snapshot here and then I'll take a heap snapshot.

[00:05:23] And so what this does is it shows me everything that's taking up memory. Before we get too much further I wanna get into the concept of garbage collection, something I've mentioned a few times. So with scripting languages where you're not manually allocating and deallocating memory, there's this kind of garbage collection.

[00:05:40] And the basic idea, it's called the mark and sweep technique. So the idea is it looks at everything that you have and it's like, are you still using this? That's basically the very simple idea. It goes from thing to thing and it's like are you using this, cool, I'll keep it, no I'm gonna get rid of it then.

[00:05:55] And so it's this process that's constantly happening, right? And so it's like, yeah, if you make an array and you do console.log it and then nothing else in that function completes and nothing else has any pointers added or anything like that. It's like, cool, nobody's pointing at you.

[00:06:11] So this is where you get in if you've heard anything like looking at JavaScript closures before. They're interesting because when you have a closure in JavaScript, it retains this reference to its outer scope, right? So you have a function that returns a function, and that inner function has this closure.

[00:06:26] So that means as long as that inner function is around, you can't get rid of the outer function cuz at any time it might call in to that, right? And so you kinda get these concepts where it's like, these are kinda pointers. Is there anything that's still around that's pointing at it?

[00:06:40] If there is, then we can't get rid of it. If there's not, then we can totally get rid of it. And so you'll see this, if you created an element, it'll put it in memory. And then you get rid of that element on the next garbage collection, it'll be cool.

[00:06:52] Nobody uses you anymore. You've been removed. We can get rid of you. So it keeps this, when coding correctly, it keeps this pretty stable area where you can just constantly be kind of cleaning up. A neat thing on the performance if you want to check garbage collections, they actually have this little can here.

[00:07:09] So you can start a performance timeline. You can manually force a garbage collection, and then you can end the performance timeline and see if everything gets cleaned up, because it probably should. But over here in memory, what you see is you see this concept of shallow and retained size, right?

[00:07:23] And this gets exactly into the garbage collection concept. So shallow is how big are you? If you're an array with 50 items in it, that is your size. That's your shallow size, right. If you're a variable, that points to another array that has a million items in it.

[00:07:40] As a variable, you're pretty small. But the thing that you point to and what retained size means is if I could get rid of you, that would let me get rid of all these other things, too, right? So think about it, if you're the last pointer, add something huge.

[00:07:54] Then your shallow size is gonna be really small, but your retained size, meaning the size that we could free up if we were able to get rid of you, is pretty large. So you'll kinda see this concept. So what we wanna know is not necessarily about retained size.

[00:08:07] We wanna know what in and of itself is the biggest, right? And so we can organize by shallow size. So we can see the biggest things on this page are strings. They're huge. And if we drill into them, we can start seeing all of these big strings that I've created.

[00:08:22] [LAUGH] That is a problem, here with the memory leak. And so this kind of gives you a pretty great idea. If it doesn't give you a really clear idea, what I mentioned you can do before is you can take multiple snapshots. So we've got our one here from when the page has just started.

[00:08:34] I'll go back to profiles and I'll just take another snapshot. So now we've got two snapshots. And instead of the summary view up here, I'll do a comparison view. So now we're comparing this snapshot two to snapshot one. And so what I wanna see is between the two because both happened after the page was finished loading.

[00:08:52] What's new, and so we can go here and we can see that, again, no surprise, just strings. But if you were unclear about what was taking up memory, you can take two snapshots at different times and compare them to each other, what has changed. And so you can see these strings have changed, these are the strings.

[00:09:06] All these strings have been added. None of them have been deleted, so there's a delta of +2,427 strings and they take up a lot of room. So you can drill down to these strings and you can see all sorts of cool stuff. You can see where they are.

[00:09:21] They live inside of these arrays, and you can see that they're in the window object. You can find all this really cool information about them. So you can kinda start narrowing down on, okay, I know I have a memory leak from the jigsaw and the task manager. I know it's string-based because the strings are the thing that are so big, and I can get some information.

[00:09:39] Some code is making these arrays full of these big strings here. And you can kind of start narrowing down what part of your code base might be doing that, based on that. There's not often a great way of jumping to sources, like we've seen in other panels. And you know the performance panel, it knows what line of code is responsible.

[00:09:57] So you can very easily hop there. And the memory panel is not keeping track of what code created that thing. So it gets a little bit harder. But it can give you a lot of really good insight on what the problem is. Is there a memory leak, what's causing it, what type of information is there?