Memory Leak Exercise

[00:00:00]
>> Jon Kuperman: All right, so with that, let's do the last exercise. So that's exercise 5, memory leaks. Again, not to be concerned necessarily with finding the area in the source code that is causing this, although feel free. But what I think would be great to do is open up that task manager, open up the performance analyzer, click memory, just kind of visualize it.

[00:00:18]
Make sure that you can see, run a performance analyzer, and then add, click this button, add a few items, and then see what it comes back with. Run a heap snapshot, compare it. Just to get a little bit hands on familiar, we'll take like, a five minute break and do that.

[00:00:31]
And then I'll kind of go through and cover when we when we meet back.
>> Speaker 2: Are there RAM tools or do RAM tools for real user metrics? Are they able to test memory usage or when someone's nearing a limit in the browser's memory?
>> Jon Kuperman: Yeah, it's such a good question, I think I would have to look a little bit more into them.

[00:00:52]
So I know that by like, Chrome does not offer APIs for CPU and memory current usage, so you can't put in real user detection, just log that out. That being said, I think that there are quite a few ways you could approximate it by looking at a bunch of different statistical that are available on the performance APIs.

[00:01:14]
So I do think that a lot of these RAM tools gather some type of memory, at least, like estimate on how much is being used. But I don't think that they're the, like, direct calling in through, like the dev tools protocol or something like that. So I do think that there are quite a few ways that you could get them and then measure that stuff.

[00:01:33]
Document size and like, JavaScript size, or there's quite a few things you get, probably through the performance APIs, but I do not believe that they give you, like a simple API for current memory usage or something like that.
>> Speaker 2: And with asynchronous programming, do promises or anything like that introduce any more difficulty with tracking memory leaks?

[00:01:54]
>> Jon Kuperman: Yeah, not necessarily like promises can introduce some difficulty with debugging, but I think largely with tracking memory leaks. I don't think so, they get slotted into the same they belong to the same tab, into the same heap, and you should be able to still run snapshots before and after and get a full description.

[00:02:12]
It's possible that things are in pending states, and misrepresenting memory usage is possible. But I think by and large, you'll still be getting accurate snapshot. So, yeah, again, I think we go into the exercise. We could start off with any of the tools, really, but we could start off with the task manager, and then, I could click this add items button a couple of times, and then I should be seeing again.

[00:02:36]
I busted myself again, because I should be doing this with an incognito window. So I can get a much better, a much simpler. So yeah, we can kind of see here how much memory we're using, like 12,000. And then we can kind of click this a few times and then see that it jumps up to like 14,000 or 15,000.

[00:02:52]
So yeah, we can see that in some way we're like retaining things here. Yeah, you can see that it's kind of like moving even though we're not doing anything. Maybe less interesting on a contrived example, but on your application, if you predict that you have a memory leak on a certain workflow, you can use tools like this to kind of get to the bottom of it.

[00:03:09]
So then I'll open up the performance tab and make sure memory is selected, and I will start an audit, and then I will click this button, and then I will stop the audit. And again, here, this is sort of the jigsaw, the feared like the pattern that you kind of don't wanna see, right?

[00:03:24]
You don't wanna to see this thing that's like growing and growing and growing and that ideally after five clicks of the button it should go back down to exactly where it was before. But this is sort of the pattern that you wanna look out for words like kind of going up and up and it allocates a bunch of memory and then when it's finished it.

[00:03:40]
It doesn't release nearly what it allocated, meaning that at least theoretically if somebody clicked this a thousand times, it would just grow, and never shrink back down. We can see right away that the memory being used is in the JS heap for this example. So again, we're kind of like narrowing in on it.

[00:03:55]
Then we can go to the memory tab and I'll go ahead and just click on a heap snapshot. Great, it's kind of huge. And then I will click add items to array a few times, and I'll make another snapshot. And again, I would expect these to be identical in size because nothing else has changed.

[00:04:11]
But in fact, they're quite different in size. And we can go through, we can do a bunch of comparisons on here or summary on here. But what I always prefer to do is to go right to the comparison and see kind of what the difference is like, what has like, the highest delta, a bunch of system stuff.

[00:04:25]
And then we can kind of see these arrays that these arrays are coming we can kind of click through to see like where inside they're kind of coming from, like these performance array timings. But again, if we were to check out the source code here, we kind of see that we basically are making these gigantic arrays.

[00:04:42]
Again, it doesn't give us the best tie in from what we're seeing in this memory tab into what actually is displayed in the source code. But you can, kind of get at least a pretty good idea of like, is it event listeners? Is it JavaScript objects? Is it arrays or strings that I'm making?

[00:05:03]
And at least tie that back into the source code that's running at the time to kind of see, yeah, to kind of see where these are coming from. You can dig a little bit a little bit deeper in, try to and kind of see what does it get called around?

[00:05:17]
What target does it get called with? So sometimes you could find a little bit of good metadata here. But again, I will say that this is like one of the hardest tools, if not the hardest tool in dev tools to, yeah, to kind of tie back in, easy to find that you have one, hard to find what's causing it, I guess is how I'd say it.