Mechanically Detect Memory Leaks With Puppeteer

Aus Vokipedia
(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „<br>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 essenti…“)
 
K
 
Zeile 1: Zeile 1:
<br>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.<br><br><br><br>But for  [https://live-nine9.com/bbs/board.php?bo_table=free&wr_id=119428 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.<br><br><br><br>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.<br><br><br><br>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 [http://dig.ccmixter.org/search?searchp=complicated 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.<br><br><br><br>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 [http://www.mecosys.com/bbs/board.php?bo_table=project_02&wr_id=6014646 Memory Wave Audio] consumption has been computed based on the newest modifications made by the code.<br>
+
<br>About half a yr ago Bronley Plumb kindly made me conscious of a memory leak in one among my open-supply packages. To see this memory leak in action it was essential to open a browser and its dev instruments to execute some guide steps. On top of that, the memory needed to be inspected manually. It was an advanced process. Normally I just add a failing test before I repair a bug. This time it was a bit extra tricky. But in the long run I discovered a way to test the memory consumption routinely and here is what I got here up with. If you aren't interested in the [https://www.accountingweb.co.uk/search?search_api_views_fulltext=adventurous%20path adventurous path] which led me to the answer be at liberty to skip proper to the end to learn on from there. What's a memory leak? In general a memory leak is the state of affairs during which a software holds on to a piece of memory which it does not really want anymore. In JavaScript this most definitely means that there's a reference to an object somewhere which you totally forgot about.<br><br><br><br>But for  [https://git-test.zcy.dev/carina57637790 MemoryWave Official] the garbage collection it's impossible to differentiate between objects which are nonetheless in use and people that have simply been forgotten someplace. Historically a memory leak was something that net builders did not need to care about. Each link on a page caused a new page to be loaded which in flip wiped the memory. However memory leaks are usually very shy and solely develop into noticeable when a specific program retains operating for a very long time. With todays Single Web page Purposes and Progressive Internet Apps the situation has changed. Many websites do behave like apps and are [https://www.reddit.com/r/howto/search?q=designed designed] to run for a very long time and that is particularly true for apps that use the net Audio API. The memory leak in question was found in standardized-audio-context which is a library to achieve cross browser compatibility for that API. Probably the most easy example of a memory leak that I could consider is attaching some metadata to an object.<br> <br><br><br>For instance you've gotten a few objects and you wish to retailer some metadata for [https://www.hanyunmedical.com/lanoramelbourn Memory Wave] each of them. However you don't wish 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 proven in the next snippet. It allows to retailer some metadata, to get it again and to delete it again. All that is needed is a Map which makes use of an object as the key to index its metadata. But what if an object with metadata just isn't referenced anywhere else anymore? It nonetheless cannot be rubbish collected because the Map nonetheless has a reference to it to index the metadata. The next instance is in fact contrived however many memory leaks could be reduced to one thing as simple as this. All the created objects do survive every garbage collection as a result of the Map still has a reference to them. This is the proper use case for a WeakMap.<br><br><br><br>The references held by a WeakMap don't prevent any object from being rubbish collected. By replacing the Map with a WeakMap this widespread cause for a memory leak might be eliminated. The issue that precipitated the memory leak in my code was very related though it was not that obvious to spot. Puppeteer is a software which can be used to remote management Chrome or some other Chromium browser. It's a simpler various to Selenium and WebDriver nevertheless it has the draw back that it only works with browsers based on Chromium (for now). It comes with access to some APIs which aren't accessible by Selenium as a result of it tries to work together with an internet site like a real user. Puppeteer then again has entry to many APIs which aren't accessible to normal users. This works by using the Chrome DevTools Protocol. A type of things that Puppeteer can do which Selenium cannot is inspecting the memory. And that is after all super useful when looking for memory leaks.<br><br><br><br>At first look there appears to be a perform within the API of Puppeteer which offers all that is required to track the memory usage. It is the web page.metrics() technique. It does among different things additionally return a metric called JSHeapUsedSize. This is the variety of bytes that V8, the JavaScript engine used in Chrome, uses as memory. Sadly getting the size of the memory will not be sufficient. The memory of a JavaScript program is managed by a very autonomous garbage assortment. Not like the garbage collection in the true world which usually exhibits up on a very strict and well known schedule the JavaScript garbage assortment does its job each time it thinks it's the fitting time to do so. It can usually not be triggered from inside the JavaScript code. But it is critical to make sure it ran before inspecting the memory to be sure that all the trash has been picked up and the memory consumption has been computed based mostly on the most recent changes made by the code.<br>

Aktuelle Version vom 14. August 2025, 12:33 Uhr


About half a yr ago Bronley Plumb kindly made me conscious of a memory leak in one among my open-supply packages. To see this memory leak in action it was essential to open a browser and its dev instruments to execute some guide steps. On top of that, the memory needed to be inspected manually. It was an advanced process. Normally I just add a failing test before I repair a bug. This time it was a bit extra tricky. But in the long run I discovered a way to test the memory consumption routinely and here is what I got here up with. If you aren't interested in the adventurous path which led me to the answer be at liberty to skip proper to the end to learn on from there. What's a memory leak? In general a memory leak is the state of affairs during which a software holds on to a piece of memory which it does not really want anymore. In JavaScript this most definitely means that there's a reference to an object somewhere which you totally forgot about.



But for MemoryWave Official the garbage collection it's impossible to differentiate between objects which are nonetheless in use and people that have simply been forgotten someplace. Historically a memory leak was something that net builders did not need to care about. Each link on a page caused a new page to be loaded which in flip wiped the memory. However memory leaks are usually very shy and solely develop into noticeable when a specific program retains operating for a very long time. With todays Single Web page Purposes and Progressive Internet Apps the situation has changed. Many websites do behave like apps and are designed to run for a very long time and that is particularly true for apps that use the net Audio API. The memory leak in question was found in standardized-audio-context which is a library to achieve cross browser compatibility for that API. Probably the most easy example of a memory leak that I could consider is attaching some metadata to an object.



For instance you've gotten a few objects and you wish to retailer some metadata for Memory Wave each of them. However you don't wish 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 proven in the next snippet. It allows to retailer some metadata, to get it again and to delete it again. All that is needed is a Map which makes use of an object as the key to index its metadata. But what if an object with metadata just isn't referenced anywhere else anymore? It nonetheless cannot be rubbish collected because the Map nonetheless has a reference to it to index the metadata. The next instance is in fact contrived however many memory leaks could be reduced to one thing as simple as this. All the created objects do survive every garbage collection 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 prevent any object from being rubbish collected. By replacing the Map with a WeakMap this widespread cause for a memory leak might be eliminated. The issue that precipitated the memory leak in my code was very related though it was not that obvious to spot. Puppeteer is a software which can be used to remote management Chrome or some other Chromium browser. It's a simpler various to Selenium and WebDriver nevertheless it has the draw back that it only works with browsers based on Chromium (for now). It comes with access to some APIs which aren't accessible by Selenium as a result of it tries to work together with an internet site like a real user. Puppeteer then again has entry to many APIs which aren't accessible to normal users. This works by using the Chrome DevTools Protocol. A type of things that Puppeteer can do which Selenium cannot is inspecting the memory. And that is after all super useful when looking for memory leaks.



At first look there appears to be a perform within the API of Puppeteer which offers all that is required to track the memory usage. It is the web page.metrics() technique. It does among different things additionally return a metric called JSHeapUsedSize. This is the variety of bytes that V8, the JavaScript engine used in Chrome, uses as memory. Sadly getting the size of the memory will not be sufficient. The memory of a JavaScript program is managed by a very autonomous garbage assortment. Not like the garbage collection in the true world which usually exhibits up on a very strict and well known schedule the JavaScript garbage assortment does its job each time it thinks it's the fitting time to do so. It can usually not be triggered from inside the JavaScript code. But it is critical to make sure it ran before inspecting the memory to be sure that all the trash has been picked up and the memory consumption has been computed based mostly on the most recent changes made by the code.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge