4 ms·
Drool: automated memory leak detection in JavaScript
- hippich 11y agoAm I correct, this tool simply compares before and after number of nodes? Or it is more capable and I am just missing something? I guess it is still valuable for CI..
- hacliff 11y agoit looks like it also lets you check memory stats and event listener counts
- samsaccone 11y agoHey Hippich, it currently gives you node count, heapsize, and eventListeners after the action is taken and a "super" GC has been run https://github.com/samccone/drool/commit/4c3ac304448509afc0827e34229999ecba707b04 https://github.com/samccone/drool/commit/4c3ac304448509afc08.... It is up to the consumer of the tool to decide what is really a failure and what actions are "clean"
- dcherman 11y agoVery cool! I was going to be sitting down soon to reason about the $compile step in Angular 1 to see if there were any leaks. It'll be interesting to run this against my test case and see what pops out. Thanks!
- wamatt 11y agoI found the author's reason for making this quite interesting After running perf/memory tests across multiple todomvc implementations, I found that almost all implementations have significant memory leaks on the most basic of tasks. Worse yet, most of these leaks were introduced at a framework level, or were introduced by "expert/(framework authors)". The question arose in my mind, if people who authored a framework are introducing leaks in the most trivial of applications, how can users be expected to create non-leaking implementations of much more complex applications.
- bestusername111 11y agoAm I the only one sick to death of fucking JavaScript? It's an abomination of a "language" but loved my web devs because hurr durr anything other than web is too hard for them.