Memory leaks and how to find them using Chrome Dev Tools

Ayush Sharma — Sat, 31 Aug 2019 14:06:38 +0000

The memory leaks are very hard to find in an application and they can be avoided during writing the code by taking some precautions. Every developer should be aware of the most common memory leak patterns.

In this article, I'll try to cover the memory lifecycle pattern in applications, the most common causes of memory leaks and how you can identify them in Chrome Dev Tools.

The Memory Lifecycle Patterns

The memory lifecycle pattern says that some memory is allocated to your code, The allocated memory is being used by your code and then it is released (freed) when your code is executed.

Causes of the Memory Leaks

1. The Accidental Global in non-strict mode

function iCauseMemoryLeak() {
  temp = 1;
}

Here, you are assigning a value to temp variable which is not available in any of the scopes of the iCauseMemoryLeak function. The Javascript compiler sets the variable in the global scope and variable temp is not garbage collected in future. It stays there forever during your application lifecycle.

2. The Forgotten Timers


setTimeout(() => {
  /** Perform a task here.. */
}, 1000);

// OR

setInterval(() => {
  /** Perform a task here.. */
}, 1000);

The timers allocates dynamic memory to perform the task and if you forget to clear the timers, then it will cause a memory leak.

You can clear the setTimeout using clearTimeout and setInterval using clearInterval


var a = setTimeout(() => {
  /** Perform a task here.. */
}, 1000);

clearTimeout(a);

// OR

var b = setInterval(() => {
  /** Perform a task here.. */
}, 1000);

clearInterval(b);

3. The DOM manipulations

Just imagine, you have two buttons and when you click on buttonOne then it will remove the buttonTwo from the DOM.


const buttonOne = document.querySelector('#button-a');
const buttonTwo = document.querySelector('#button-b');

buttonOne.addEventListener('click', () => {
    document.body.removeChild(buttonTwo);
});

In the above code, you remove the buttonTwo from DOM by clicking buttonOne, but we never remove the reference of buttonTwo which is stored in the variable buttonTwo. This kind of memory leak can be very dangerous.

We can avoid this by storing the reference of buttonTwo inside the click event listener.

const buttonOne = document.querySelector('#button-a');

buttonOne.addEventListener('click', () => {
    const buttonTwo = document.querySelector('#button-b');
    document.body.removeChild(buttonTwo);
});

Here, We remove the buttonTwo from the DOM by clicking on buttonOne and it is Garbage collected.

Identification in Chrome Dev Tools

Open Chrome dev tools.
Load your website.
Select Memory checkbox in the performance panel and the click on Reload icon.

Load the profile and memory graphs.

Analysing the Memory Graphs

Image A

Image B

What do you think? Which image does represent memory leak?

Let's find the answer by following the Memory Lifecycle Pattern.

Allocate memory, Use memory and Release memory.

In image A, The application starts, it uses some memory and then releases it and this nature follows until the application is in loading state. In the end, when the application is loaded, you can notice that the graphs stay almost linear and flat. It indicates that application with image A needs that reserved memory for the application run time and the required memory is constant.

While, on the other hand, In image B, The memory graphs are always increasing till the end, they are a step function and these graphs represent the increase in memory over time.

Now, we can say that image B represents the memory leak.

I hope you enjoy reading this article. Happy learning.

P.S. Can you guess the website in Image A of which I generated the memory graphs?

References:

Is your code fast enough? Let's find out in Chrome Dev Tools

Ayush Sharma — Fri, 30 Aug 2019 18:17:26 +0000

We all have that curiosity to find out that is my code fast enough, when is it loaded in the application lifecycle, and what is the execution time, or what happens in the application when you just add a function block.

Chrome dev tool is really powerful enough to find out answers of all these questions. You can use the performance API to analyse the role of a code block inside your application.

Let's find out the execution time of `for` loop to perform `1000000000` iterations.

  performance.mark("start"); // start marker 

  for(let i = 0; i < 1000000000; i += 1){}

  performance.mark("end"); // end marker 
  performance.measure("for loop performance report", "start", "end");

  const measurements = performance.getEntriesByType("measure");
  console.log(measurements);

When you run the above code in the browser, you can find the performance in chrome dev tools.

Load your application.
Open Chrome developer tools.
Select the Performance tab.
Record the new profiling by clicking on the reload icon.
Check the execution time inside the timing section.

You can clearly notice that for loop is executed for 544ms before the FMP(First meaningful paint) and after the onload events.

I hope you find the article useful. Happy learning. ☺️

DEV Community: Ayush Sharma