This post is number one in a three part series about memory consumption for web applications in general.
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 - http://msdn.microsoft.com/en-us/library/Bb250448. 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 - http://msdn.microsoft.com/en-us/library/Bb250448. 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 - http://home.orange.nl/jsrosman/ – 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:
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.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.