This post is number one in a three part series about memory consumption for web applications in general.
Since the Web 2.0 era, Web Applications have changed for the better. They provide more functionality, better usability and improved performance. However this tendency led to increased complexity. It is not unusual for a user to stay on a single page for hours without leaving. The browser would just poll data from the server through Ajax requests and display it in even more interesting manners. Therefore it is no wonder that web applications have become hungrier for resources and the browsers couldn’t keep up with it. The heavy utilization of JavaScript and DOM revealed the poor memory management of most of the major browsers at the time. These issues still persist nowadays and it is our duty as developers to be aware of them.
There seems to be a slight confusion among Web developers, when it comes to separating Memory Leaks issues from Memory Consumption. In order to get things clear, let’s investigate the definitions of both.
Memory consumption stands for the amount of memory a particular program utilizes throughout its execution. This term is self-explanatory as every application relies on the underlying memory to store instances of variables. The more the variables, the larger the memory consumption will be. Therefore it is a common assumption that more complicated applications require more memory.
Memory leaks are a specific case of using the memory, or more precisely misusing it. Memory leaks are bugs in the memory management of either the platform (browser) or the application itself. When a program occupies a piece of memory and later does not release it, this memory becomes useless and inaccessible. Reproducing this process for a long time may lead to memory starvation – a special case, in which the application is unable to continue the execution due to insufficient memory resources. The application becomes slower, less responsive and eventually crashes.
It is a well-known fact that the memory management of older versions of the Internet Explorer browser has been poor, with Internet Explorer 6 being the most notorious of them. Here is one very famous article on the topic by Justin Rogers - (update 2/2019: the article is no longer available on Microsoft's site, but this forum discussion on the topic is still relevant: https://blogs.msdn.microsoft.com/ie/2005/06/21/leak-patterns/). However memory leaks are not limited to IE, almost any browser will leak memory under the right circumstances. A simple search through the bug list should be just enough to understand it. Still, in my opinion, Internet Explorer has proven itself as one with the most issues, when memory leaks are concerned.
Memory leaks are caused by specific programming patterns, whose understanding is quite valuable. Very often they are divided in the following categories:
This classification has been taken from the previously mentioned article - (update 2/2019: the article is no longer available on Microsoft's site, but this forum discussion on the topic is still relevant: https://blogs.msdn.microsoft.com/ie/2005/06/21/leak-patterns/). In order to stay true to the DRY principle, I will skip the extensive explanation and code samples for each category, as they are already explained there.
Still we cannot miss the fun part of writing and changing some example code. Before that, one should have the necessary tools at hand. In order to observe the “diminishing” memory, the easiest way is to open the Task Manager/Process Explorer/Activity Manager and observe the consumed memory there. A better option is to use sIEve - https://www.softpedia.com/get/Programming/Other-Programming-Files/sIEve.shtml – a tool specially designed to track memory usage and detect memory leaks under IE. The page is loaded in the sIEve environment and two scenarios could follow:
Source: (update 2/2019: the above was sourced from the sIEve homepage, which is no longer available)
An interesting effect can be observed, when upgrading the installed Internet Explorer to the latest version - 9, i.e. many examples that produce leaked memory in the latter case will not leak. This should lead to the conclusion that Microsoft has improved the memory management in Internet Explorer 9 compared to the previous versions.
The next post in this series will show particular examples of memory leaks with code samples of the different types of leaks.
Nikodim Lazarov is a Senior Software Developer in the Telerik's ASP.NET AJAX devision. He has years of experience building web applications of various scales. Niko is a strong advocate of Web standards, TDD, Agile and basically anything that makes every developer a true craftsman. Outside of office he usually rides his bike, goes kayaking or is simply out with friends.