[neetodavid]

Being able to automate tests for memory leaks is very helpful but I would much rather incorporate the browser dev tools than not when debugging memory. Doing it only in javascript feels very janky (weak maps, attaching giant array objects to things, waiting ?? amount of time for the automated GC to run).

I was debugging memory leaks in some pretty large javascript products and while I did initially start with methods like this post, I only started to make reliable progress when I became familiar with the heap snapshot tool. Diagnosing problem is trivial (just filter the heap snapshot by a Class name and count the instances) and it is The Tool To Use to actually resolve it (tracing the chain of references in the retainers view)

In the future if I need to write automated tests to identify memory leaks I will look into automating the Dev Tools rather than fumbling with WeakMap or performance.memory.usedJSHeapSize

[hoten]

I used the chrome devtools protocol to write a memory leak detector for my game. Has helped me quite a bit. If you like I can share the source.

[hoten]

Here it is: https://gist.github.com/connorjclark/549fa524a0b8fdc8bbb1b48...

I left some annotations in a comment. Hope it helps!

[gargarplex]

+1.

[iaml]

Would be very useful for me

[londons_explore]

The devtools protocol is super simple. It's very easy to automate everything devtools can do. You can do it with something high level like puppeteer/selenium, or just directly with a websocket to the browser.

The API is documented here:. https://chromedevtools.github.io/devtools-protocol/

[Sophistifunk]

It'd be better if the committee would just stop pretending that JS has some sort of holy determinism that would go away if we were allowed weak references. They're going to have to put it in soon anyway in order to support wasm refs.

[darepublic]

I guess I'm a noob but I always stumble when trying to use the chrome dev tool profiling.. I love other aspects of the dev tools but not that