Problems finding memory leaks in a web app using Chrome DevTools
Google Chrome browser comes with excellent tools for the developer, they are also in Yandex. Browser, the new Opera, and in other browsers based on Chromium.
Among them 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 the example of Yandex.Mail” .
Javascript keeps an object in memory as long as there is at least one link 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 remove all references 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 during the operation of the application in the console debugging information is displayed, then before measuring the memory, the console should be cleared.
This does not necessarily lead to a decrease in memory consumption, but in my practice I have already encountered cases where clearing the console freed objects from memory.
In my case, these were “JavaScript frameworks debugging” and “Support asynchronous call stacks”, which is already out of experimental.
As long as they were included, some of the objects in the memory were not deleted by the garbage collector, although there were no references to them in the application itself.
When I removed the checkmarks, the problems disappeared.
By the way, in the application that I am developing, complex templates are being rendered on AngularJS, and with the experimental features turned on, the render lasted about 10 seconds, and with those turned off - only 3.
How can things be with other experimental functions, I can not say, but I advise you to turn everything off during the search for memory leaks.
In my case it was Batarang. It is a tool for debugging applications built on AngularJS, and it stores references to the scope of the application inside, which caused a memory leak.
After I turned off the extension, the memory began to free up.
There can be many plug-ins that affect memory management. According to the link that I gave at the beginning of the article, it is recommended to disable all plug-ins in general, which I think is the right advice.
This function is needed in order to determine at what time how much memory is stored by the application, and what exactly is at what point is delayed. This is a very useful thing, but there are some peculiarities in the operation of this function.
The first is that the function shows not only how much memory is being deposited, but also how much is freed up (“free” memory becomes light gray), while it may not always be accurate to show.
In order to understand at what point how much memory is used, you should use the Timeline.
For the test, I repeated several times one action in the application, and watched what was happening with the memory.
Record Heap Allocations showed that the memory was not completely cleared, and after each action there was a little busy memory, while Timeline showed that everything cleared well and there were no leaks.
The second is that 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 the Timeline will show that the memory is flowing, that is, it is being used more and more.
If you turn on Timeline alone, the memory will not flow, which leads to the conclusion that Record Heap Allocations holds references to objects, and therefore is not suitable for tracking the "release" of memory.
In the article, I gave 4 examples of places where references to objects that can be prevented by the garbage collector can be stored.
Naturally, these are not all problem areas, but only those that I personally encountered.
Some of this may have already been corrected, and something may be corrected in the future.
It is important to understand that in addition to the application being developed, links may be stored in other places, and this should be taken into account when searching for memory leaks.
Among them 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 the example of Yandex.Mail” .
Javascript keeps an object in memory as long as there is at least one link 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 remove all references 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 during the operation of the application in the console debugging information is displayed, then before measuring the memory, the console should be cleared.
This does not necessarily lead to a decrease in memory consumption, but in my practice I have already encountered cases where clearing the console freed objects from memory.
2. Included experimental browser features.
In my case, these were “JavaScript frameworks debugging” and “Support asynchronous call stacks”, which is already out of experimental.
As long as they were included, some of the objects in the memory were not deleted by the garbage collector, although there were no references to them in the application itself.
When I removed the checkmarks, the problems disappeared.
By the way, in the application that I am developing, complex templates are being rendered on AngularJS, and with the experimental features turned on, the render lasted about 10 seconds, and with those turned off - only 3.
How can things be with other experimental functions, I can not say, but I advise you to turn everything off during the search for memory leaks.
3. Browser extensions.
In my case it was Batarang. It is a tool for debugging applications built on AngularJS, and it stores references to the scope of the application inside, which caused a memory leak.
After I turned off the extension, the memory began to free up.
There can be many plug-ins that affect memory management. According to the link that I gave at the beginning of the article, it is recommended to disable all plug-ins in general, which I think is the right advice.
4. Record Heap Allocations feature.
This function is needed in order to determine at what time how much memory is stored by the application, and what exactly is at what point is delayed. This is a very useful thing, but there are some peculiarities in the operation of this function.
The first is that the function shows not only how much memory is being deposited, but also how much is freed up (“free” memory becomes light gray), while it may not always be accurate to show.
In order to understand at what point how much memory is used, you should use the Timeline.
For the test, I repeated several times one action in the application, and watched what was happening with the memory.
Record Heap Allocations showed that the memory was not completely cleared, and after each action there was a little busy memory, while Timeline showed that everything cleared well and there were no leaks.
The second is that 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 the Timeline will show that the memory is flowing, that is, it is being used more and more.
If you turn on Timeline alone, the memory will not flow, which leads to the conclusion that Record Heap Allocations holds references to objects, and therefore is not suitable for tracking the "release" of memory.
Conclusion
In the article, I gave 4 examples of places where references to objects that can be prevented by the garbage collector can be stored.
Naturally, these are not all problem areas, but only those that I personally encountered.
Some of this may have already been corrected, and something may be corrected in the future.
It is important to understand that in addition to the application being developed, links may be stored in other places, and this should be taken into account when searching for memory leaks.
Source: https://habr.com/ru/post/236447/
All Articles