youtube.com
About half a yr in the past Bronley Plumb kindly made me conscious of a memory leak in one in all my open-supply packages. To see this memory leak in motion it was essential to open a browser and its dev tools to execute some manual steps. On top of that, cognitive enhancement tool the memory needed to be inspected manually. It was a complicated process. Normally I just add a failing check earlier than I fix a bug. This time it was a bit more tricky. But ultimately I found a means to check the memory consumption routinely and cognitive enhancement tool here is what I got here up with. If you are not fascinated within the adventurous path which led me to the solution be at liberty to skip proper to the tip to read on from there. What's a memory leak? On the whole a memory leak is the state of affairs in which a software holds on to a bit of memory which it would not actually need anymore. In JavaScript this most likely means that there is a reference to an object somewhere which you totally forgot about.
But for the rubbish assortment it is unimaginable to distinguish between objects which are nonetheless in use and those that have just been forgotten somewhere. Historically a memory leak was something that internet builders did not need to care about. Each link on a page triggered a brand new page to be loaded which in turn wiped the memory. But memory leaks are normally very shy and only develop into noticeable when a selected program retains operating for a very long time. With todays Single Web page Applications and Progressive Web Apps the scenario has modified. Many web sites do behave like apps and are designed to run for a long time and that is especially true for apps that use the web Audio API. The memory leak in question was found in standardized-audio-context which is a library to realize cross browser compatibility for that API. Essentially the most simple example of a memory leak that I may think of is attaching some metadata to an object.
As an instance you've got a couple of objects and you wish to retailer some metadata for each of them. But you don't need to set a property on those objects because you need to maintain the metadata in a separate place. This can be solved through the use of a Map as shown in the following snippet. It permits to store some metadata, to get it back and to delete it once more. All that is required is a Map which makes use of an object as the important thing to index its metadata. But what if an object with metadata is not referenced anywhere else anymore? It nonetheless cannot be rubbish collected because the Map still has a reference to it to index the metadata. The next example is of course contrived but many memory leaks may be lowered to something so simple as this. All of the created objects do survive each garbage collection because the Map still has a reference to them. That is the perfect use case for Memory Wave a WeakMap.
The references held by a WeakMap don't forestall any object from being garbage collected. By replacing the Map with a WeakMap this frequent trigger for a memory leak could be eradicated. The issue that prompted the memory leak in my code was very similar although it was not that obvious to identify. Puppeteer is a software which can be used to remote control Chrome or every other Chromium browser. It's a easier alternative to Selenium and WebDriver but it surely has the downside that it only works with browsers based on Chromium (for Memory Wave now). It comes with access to some APIs which aren't accessible by Selenium as a result of it tries to work together with a website like an actual user. Puppeteer however has entry to many APIs which aren't accessible to regular users. This works by utilizing the Chrome DevTools Protocol. A type of issues that Puppeteer can do which Selenium can't is inspecting the memory. And this is in fact tremendous helpful when looking for memory leaks.
At first look there seems to be a function within the API of Puppeteer which gives all that is required to trace the memory utilization. It's the page.metrics() methodology. It does amongst other issues additionally return a metric known as JSHeapUsedSize. That is the variety of bytes that V8, the JavaScript engine used in Chrome, makes use of as memory. Sadly getting the dimensions of the memory is just not enough. The memory of a JavaScript program is managed by a very autonomous rubbish assortment. In contrast to the garbage assortment in the real world which often shows up on a very strict and well-known schedule the JavaScript garbage assortment does its job at any time when it thinks it is the correct time to take action. It will probably usually not be triggered from inside the JavaScript code. However it is critical to verify it ran earlier than inspecting the memory to make sure that all of the trash has been picked up and the memory consumption has been computed based on the most recent changes made by the code.