Mastering Chrome Developer Tools, v4

Understanding Garbage Collection

Jon Kuperman
Bloomberg
Mastering Chrome Developer Tools, v4

Lesson Description

The "Understanding Garbage Collection" Lesson is part of the full, Mastering Chrome Developer Tools, v4 course featured in this preview video. Here's what you'd learn in this lesson:

Jon discussing identifying memory leaks in Chrome DevTools and suggests using the task manager to monitor memory usage in browser tabs and the performance tab to track memory over time. By observing patterns and looking for steady state memory usage, developers can identify potential memory leaks in their applications.

Preview
Close

Transcript from the "Understanding Garbage Collection" Lesson

[00:00:00]
>> Jon Kuperman: The first thing that can be a little bit difficult is like understanding if I have a memory leak? And that can be, I think the easier side [LAUGH], and then figuring out why I have a memory leak is the much harder side. And I will give the caveat here that while I don't have any great ideas for improvements, I think that finding the specific cause of a memory leak.

[00:00:19]
In Chrome DevTools is one of the most difficult workflows remaining today where it can be very easy to discover that you have one. And it can be very challenging to discover what application code because all that they give you via gives you access to low level things allocated.

[00:00:36]
But it doesn't always say this comes from this react component, like drawing that line can be very challenging still, and we'll get into that with the exercise. But a few cool things, one that I love, which is technically outside of the Chrome DevTool scope, but it is part of the Chromium tooling, is you can go to the hamburger menu.

[00:00:55]
And then you can go to More Tools, and then you can go to Task Manager, and that will open this kind of cool task manager that's just based on each browser tab that you have open, also some extensions, things like that. And you can sort that over here.

[00:01:10]
I think actually, it might not be a default. You might have to right click and add JavaScript memory, but if you do so, you can sort that in descending order, and you can not only see which one of your tabs is using the most memory. But you can watch it for a minute while it's in a steady state.

[00:01:24]
You would not expect any of these tabs to be using more and more memory because they're not doing anything. So, you can just use this as a tab test manager to kind of keep an eye on things and see if you do, in fact, have something that's just growing and growing with its JavaScript memory usage.

[00:01:38]
I just think that's a cool, yeah, quite easy to use cool thing. Another thing that you can do, going back into here, is when you do a performance audit, like we had just done in the last session, you can click Memory here, and it'll keep track of memory over time as well.

[00:01:53]
So, if I hit record on that, I make some divs or whatever the button does, and then I hit Stop on that. I'll not only get access to all that great JavaScript, so let me hide this for a second. All that great kind of stuff that we saw in the last session, where we're seeing all the JavaScript code that gets called and things like that.

[00:02:10]
But I'll also get this really nice chart down here that will show up. This shows how much memory is used and what is using it. So, whether it's regular JavaScript heat, whether its document bits being created, whether it's nodes, like DOM nodes, event listeners, or anything in the GPU memory.

[00:02:26]
Again, this isn't going to help you, or it isn't going to get you to the line of code that's leaking memory. But it is gonna give you a really good understanding if you run your app over time or if you have a memory leak or not. So, one example is when you're looking at patterns like using memory is never a problem.

[00:02:42]
That's what we do as application developers. We use memory, but we ought to be releasing our memory. And so, you ought to see these kind of shapes where you use a bunch of memory and then you release a bunch of memory. And like in an ideal world, your app at any state, and you do something and you go back to that state should use an identical amount of memory before and after.

[00:03:02]
Right now, you may leave some things around that are helper methods. If it gets called again, you may cache so there might be differences. But what you don't want to see is like, what we call like the sawtooth, like where it's growing up and up and up and up over time.

[00:03:14]
This would indicate that you have some kind of leak where you use, use 100 and you then you return 20, and then you use 100, and then you return 20, something like that. You're getting into something where there's probably a lot of stuff being retained that is unintentional.

[00:03:27]
So, one first place I like to go is that More Tools Task Manager, see if your memory's growing. The next place that I like to go is this Performance tab. Click Memory, let your app be in steady state for a little bit, and look for anything that's obviously growing.

[00:03:41]
So here it does look like for the most part in this one we're using and then releasing back down again. However, I do imagine on a lot of people, especially complex applications, if you do your first performance analysis, you'll often find memory leaks or something being retained and not given back.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Start a 7-Day Free Trial