September 11, 2014 at 11:43Problems finding a memory leak in a web application using Chrome DevTools
The Google Chrome browser comes with excellent developer tools, they are also in Yandex.Browser, the new Opera, and in other browsers based on Chromium.
Among them there are amazing tools for working with memory, which can be found in the article by Panya user - "How to find and fix memory leaks using Yandex.Mail as an example . "
Javascript stores an object in memory as long as there is at least one reference to it. As soon as you delete all references to an object, it is destroyed by the garbage collector.
Thus, to delete an object, you need to delete all links to it.
It seems very simple, but there are several rather unexpected “places” where references to objects can be stored, thereby delaying their removal and creating a memory leak.
If debugging information is displayed in the console during the application’s operation, the console should be cleared before measuring memory.
This will not necessarily lead to a decrease in memory consumption, but in my practice I have already encountered cases where cleaning the console freed objects from memory.
In my case, it was “JavaScript frameworks debugging” and “Support asynchronous call stacks”, which has already left experimental ones.
Until they were turned on, some of the objects in memory were not deleted by the garbage collector, although there were no references to them in the application itself.
When I unchecked, the problems disappeared.
By the way, in the application that I am developing, complex templates are rendered on AngularJS, and with the experimental functions turned on, the rendering lasted about 10 seconds, and with disabled ones only 3.
I can’t say how things are with other experimental functions, but I advise for a while search for memory leaks to disable everything.
In my case, it was Batarang. This is a tool for debugging applications built on AngularJS, and it internally saves references to the scope of the application, which created a memory leak.
After I turned off the extension, the memory began to be freed.
There can be many plugins that affect working with memory. Using the link that I gave at the beginning of the article, it is recommended to disable all plugins in general, which, in my opinion, is the right advice.
This function is needed in order to determine at what point how much memory is stored by the application, and what exactly is stored at what point. This is a very useful thing, but there are some features to this function.
First , the function not only shows how much memory is being saved, but also how much is freed up (the “free” memory becomes light gray), while it may not always show accurately.
In order to understand at what point how much memory is used, it is worth using Timeline.
For the test, I repeated many times one action in the application, and watched what happens to the memory.
Record Heap Allocations showed that the memory was not completely cleared, and after each action there was a bit of occupied memory, while Timeline showed that everything cleared well and there were no leaks.
Second , you should not use Record Heap Allocations and Timeline at the same time.
If you turn on Record Heap Allocations and Timeline at the same time, then Timeline will show that the memory is flowing, that is, it is being used in more and more volume.
If you enable Timeline alone, the memory will not leak, which leads to the conclusion that Record Heap Allocations holds references to objects, and therefore is unsuitable for tracking memory “free”.
In the article, I gave 4 examples of places where references to objects that prevent their removal by the garbage collector can be saved.
Naturally, these are not all problem areas, but only those that I personally encountered.
Some of this may already have been fixed, and some may be fixed in the future.
It is important to understand that in addition to the application being developed, links can be stored in other places, and this should be taken into account when searching for memory leaks.
Among them there are amazing tools for working with memory, which can be found in the article by Panya user - "How to find and fix memory leaks using Yandex.Mail as an example . "
Javascript stores an object in memory as long as there is at least one reference to it. As soon as you delete all references to an object, it is destroyed by the garbage collector.
Thus, to delete an object, you need to delete all links to it.
It seems very simple, but there are several rather unexpected “places” where references to objects can be stored, thereby delaying their removal and creating a memory leak.
1. Console output.
If debugging information is displayed in the console during the application’s operation, the console should be cleared before measuring memory.
This will not necessarily lead to a decrease in memory consumption, but in my practice I have already encountered cases where cleaning the console freed objects from memory.
2. Included experimental browser features.
In my case, it was “JavaScript frameworks debugging” and “Support asynchronous call stacks”, which has already left experimental ones.
Until they were turned on, some of the objects in memory were not deleted by the garbage collector, although there were no references to them in the application itself.
When I unchecked, the problems disappeared.
By the way, in the application that I am developing, complex templates are rendered on AngularJS, and with the experimental functions turned on, the rendering lasted about 10 seconds, and with disabled ones only 3.
I can’t say how things are with other experimental functions, but I advise for a while search for memory leaks to disable everything.
3. Browser Extensions.
In my case, it was Batarang. This is a tool for debugging applications built on AngularJS, and it internally saves references to the scope of the application, which created a memory leak.
After I turned off the extension, the memory began to be freed.
There can be many plugins that affect working with memory. Using the link that I gave at the beginning of the article, it is recommended to disable all plugins in general, which, in my opinion, is the right advice.
4. Function "Record Heap Allocations".
This function is needed in order to determine at what point how much memory is stored by the application, and what exactly is stored at what point. This is a very useful thing, but there are some features to this function.
First , the function not only shows how much memory is being saved, but also how much is freed up (the “free” memory becomes light gray), while it may not always show accurately.
In order to understand at what point how much memory is used, it is worth using Timeline.
For the test, I repeated many times one action in the application, and watched what happens to the memory.
Record Heap Allocations showed that the memory was not completely cleared, and after each action there was a bit of occupied memory, while Timeline showed that everything cleared well and there were no leaks.
Second , you should not use Record Heap Allocations and Timeline at the same time.
If you turn on Record Heap Allocations and Timeline at the same time, then Timeline will show that the memory is flowing, that is, it is being used in more and more volume.
If you enable Timeline alone, the memory will not leak, which leads to the conclusion that Record Heap Allocations holds references to objects, and therefore is unsuitable for tracking memory “free”.
Conclusion
In the article, I gave 4 examples of places where references to objects that prevent their removal by the garbage collector can be saved.
Naturally, these are not all problem areas, but only those that I personally encountered.
Some of this may already have been fixed, and some may be fixed in the future.
It is important to understand that in addition to the application being developed, links can be stored in other places, and this should be taken into account when searching for memory leaks.