Routinely Detect Memory Leaks With Puppeteer > 자유게시판

About half a 12 months in the past Bronley Plumb kindly made me aware of a memory leak in one in all my open-source packages. To see this memory leak in motion it was necessary to open a browser and its dev instruments to execute some guide steps. On prime of that, Memory Wave Experience the memory needed to be inspected manually. It was a complicated process. Normally I simply add a failing test earlier than I repair a bug. This time it was a bit extra tricky. However ultimately I found a approach to test the memory consumption automatically and right here is what I came up with. If you aren't involved in the adventurous path which led me to the answer be at liberty to skip proper to the top to read on from there. What is a memory leak? On the whole a memory leak is the scenario in which a software program holds on to a chunk of memory which it doesn't really need anymore. In JavaScript this more than likely means that there is a reference to an object someplace which you completely forgot about.

However for the rubbish collection it is unimaginable to distinguish between objects that are nonetheless in use and people which have just been forgotten someplace. Historically a Memory Wave Experience leak was one thing that web developers did not must care about. Every hyperlink on a page prompted a new web page to be loaded which in turn wiped the memory. But memory leaks are often very shy and only grow to be noticeable when a selected program keeps running for a very long time. With todays Single Web page Purposes and Progressive Net Apps the state of affairs has changed. Many websites 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 present in standardized-audio-context which is a library to attain cross browser compatibility for that API. Probably the most simple instance of a memory leak that I might consider is attaching some metadata to an object.

As an instance you might have a few objects and also you need to store some metadata for every of them. But you don't want to set a property on these objects because you want to maintain the metadata in a separate place. This may be solved by utilizing a Map as proven in the next snippet. It allows to retailer some metadata, to get it back and to delete it again. All that is needed is a Map which makes use of an object as the important thing to index its metadata. However what if an object with metadata is not referenced anywhere else anymore? It still can't be garbage collected as a result of the Map still has a reference to it to index the metadata. The next instance is of course contrived but many memory leaks might be decreased to something as simple as this. All the created objects do survive every rubbish assortment because the Map nonetheless has a reference to them. That is the right use case for a WeakMap.

The references held by a WeakMap don't forestall any object from being rubbish collected. By changing the Map with a WeakMap this widespread trigger for a memory leak may be eliminated. The issue that brought on the memory leak in my code was very comparable although it was not that obvious to spot. Puppeteer is a instrument which can be utilized to remote management Chrome or some other Chromium browser. It's a less complicated various to Selenium and WebDriver however it has the downside that it only works with browsers primarily based on Chromium (for now). It comes with access to some APIs which are not accessible by Selenium as a result of it tries to work together with a web site like a real consumer. Puppeteer then again has entry to many APIs which are not accessible to regular customers. This works by utilizing the Chrome DevTools Protocol. A type of things that Puppeteer can do which Selenium can't is inspecting the memory. And this is in fact tremendous useful when trying to find memory leaks.

At first look there appears to be a perform within the API of Puppeteer which offers all that is needed to trace the memory usage. It is the page.metrics() methodology. It does amongst different things also return a metric referred to as JSHeapUsedSize. That is the variety of bytes that V8, the JavaScript engine used in Chrome, Memory Wave uses as memory. Sadly getting the dimensions of the memory is not sufficient. The memory of a JavaScript program is managed by a very autonomous garbage assortment. Unlike the garbage collection in the real world which normally exhibits up on a very strict and well known schedule the JavaScript rubbish assortment does its job at any time when it thinks it's the precise time to take action. It will probably usually not be triggered from inside the JavaScript code. Nevertheless it is critical to ensure it ran earlier than inspecting the memory to make certain that all the trash has been picked up and the memory consumption has been computed based mostly on the latest adjustments made by the code.