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

About half a 12 months ago Bronley Plumb kindly made me aware of a memory leak in one in all my open-source packages. To see this memory leak in action it was necessary to open a browser and its dev instruments to execute some manual steps. On high of that, the memory had to be inspected manually. It was an advanced procedure. Normally I simply add a failing take a look at before I fix a bug. This time it was a bit more tough. However in the end I discovered a means to check the memory consumption mechanically and here is what I got here up with. If you aren't involved in the adventurous path which led me to the answer feel free to skip proper to the top to read on from there. What's a memory leak? Usually a memory leak is the scenario through which a software program holds on to a bit of memory which it would not really need anymore. In JavaScript this most definitely means that there is a reference to an object somewhere which you completely forgot about.

However for the rubbish assortment it is inconceivable to differentiate between objects which are still in use and people that have simply been forgotten someplace. Historically a memory leak was one thing that web developers didn't must care about. Each hyperlink on a web page brought on a new page to be loaded which in flip wiped the memory. But memory leaks are normally very shy and only become noticeable when a specific program keeps running for Memory Wave a very long time. With todays Single Web page Purposes and Progressive Net Apps the situation has changed. Many web sites do behave like apps and are designed to run for MemoryWave a long time and that is particularly true for apps that use the net Audio API. The memory leak in question was present in standardized-audio-context which is a library to attain cross browser compatibility for that API. Probably the most simple example of a memory leak that I might consider is attaching some metadata to an object.

For instance you've gotten a few objects and MemoryWave also you want to store some metadata for every of them. But you do not need to set a property on these objects since you need to maintain the metadata in a separate place. This can be solved through the use of 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 makes use of an object as the key to index its metadata. However what if an object with metadata is just not referenced anyplace else anymore? It nonetheless can't be garbage collected as a result of the Map nonetheless has a reference to it to index the metadata. The next instance is after all contrived but many memory leaks will be reduced to one thing so simple as this. All of the created objects do survive every rubbish assortment because the Map still has a reference to them. This is the perfect use case for a WeakMap.

The references held by a WeakMap do not stop any object from being rubbish collected. By replacing the Map with a WeakMap this widespread cause for Memory Wave a memory leak may be eradicated. The issue that caused the memory leak in my code was very comparable though it was not that obvious to identify. Puppeteer is a tool which can be used to remote management Chrome or any other Chromium browser. It's a easier different to Selenium and WebDriver nevertheless it has the downside that it only 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 web site like a real user. Puppeteer on the other hand has entry to many APIs which are not accessible to regular customers. This works by using the Chrome DevTools Protocol. A type of things that Puppeteer can do which Selenium can't is inspecting the memory. And this is of course tremendous helpful when trying to find memory leaks.

At first glance there seems to be a function in the API of Puppeteer which offers all that is required to track the memory utilization. It's the page.metrics() method. It does among other things additionally return a metric referred to as JSHeapUsedSize. This is the variety of bytes that V8, the JavaScript engine utilized in Chrome, uses as memory. Unfortunately getting the size of the memory will not be sufficient. The memory of a JavaScript program is managed by a really autonomous garbage assortment. Unlike the garbage collection in the real world which usually exhibits up on a really strict and well known schedule the JavaScript rubbish assortment does its job whenever it thinks it is the right time to do so. It could usually not be triggered from inside the JavaScript code. But it is important to make sure it ran earlier than inspecting the memory to ensure that all of the trash has been picked up and the memory consumption has been computed based mostly on the most recent changes made by the code.