Mechanically Detect Memory Leaks With Puppeteer

Aus Vokipedia
Version vom 7. August 2025, 18:33 Uhr von LiliaMaki746 (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche


About half a yr ago Bronley Plumb kindly made me aware of a memory leak in one of my open-source 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 high of that, the memory had to be inspected manually. It was a complicated procedure. Normally I simply add a failing take a look at earlier than I repair a bug. This time it was a bit more difficult. But ultimately I found a method to test the memory consumption automatically and here is what I came up with. If you are not involved within the adventurous path which led me to the solution be at liberty to skip proper to the end to read on from there. What is a memory leak? Normally a memory leak is the situation wherein a software program holds on to a bit of memory which it would not really need anymore. In JavaScript this most likely means that there's a reference to an object someplace which you totally forgot about.



But for Memory Wave the garbage assortment it's not possible to tell apart between objects which are still in use and people which have just been forgotten somewhere. Historically a memory leak was something that web developers did not should care about. Each link on a page caused a new page to be loaded which in turn wiped the memory. However memory leaks are often very shy and solely turn out to be noticeable when a selected program retains running for a very long time. With todays Single Web page Purposes and Progressive Web Apps the state of affairs has modified. Many web sites do behave like apps and are designed to run for a long time and that is particularly true for apps that use the web Audio API. The memory leak in query was found in standardized-audio-context which is a library to attain cross browser compatibility for that API. The most easy example of a memory leak that I could think of is attaching some metadata to an object.



Let's say you have a few objects and you want to retailer some metadata for every of them. However you don't need to set a property on those objects because you need to keep the metadata in a separate place. This can be solved by using a Map as proven in the next snippet. It allows to retailer some metadata, to get it back and to delete it once more. All that is required is a Map which uses an object as the key to index its metadata. However what if an object with metadata will not be referenced anywhere else anymore? It nonetheless cannot be rubbish collected because the Map still has a reference to it to index the metadata. The following example is after all contrived however many memory leaks will be lowered to one thing as simple as this. All the created objects do survive each rubbish assortment as a result of the Map still has a reference to them. This is the proper use case for a WeakMap.



The references held by a WeakMap don't stop any object from being rubbish collected. By replacing the Map with a WeakMap this frequent cause for a memory leak can be eradicated. The issue that precipitated the memory leak in my code was very similar though it was not that apparent to identify. Puppeteer is a instrument which can be used to remote management Chrome or any other Chromium browser. It is a less complicated different to Selenium and WebDriver but it surely has the draw back that it solely works with browsers based mostly on Chromium (for now). It comes with entry to some APIs which are not accessible by Selenium because it tries to work together with a website like an actual user. Puppeteer alternatively has access to many APIs which are not accessible to normal customers. This works by using the Chrome DevTools Protocol. A kind of things that Puppeteer can do which Selenium can't is inspecting the memory. And this is of course super useful when looking for memory leaks.



At first look there appears to be a operate in the API of Puppeteer which gives all that is needed to track the memory usage. It's the page.metrics() technique. It does among other things 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. Unfortunately getting the size of the memory shouldn't be enough. The memory of a JavaScript program is managed by a really autonomous garbage assortment. Not like the rubbish assortment in the true world which usually shows up on a really strict and well-known schedule the JavaScript rubbish collection does its job whenever it thinks it is the proper time to do so. It might normally not be triggered from throughout the JavaScript code. But it surely is critical to ensure it ran before inspecting the memory to ensure that all the trash has been picked up and the Memory Wave Audio consumption has been computed based on the newest modifications made by the code.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge