Am 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..
Very 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.
I 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.
Am 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.
6 comments
[ 13.6 ms ] story [ 403 ms ] threadIt is up to the consumer of the tool to decide what is really a failure and what actions are "clean"
Thanks!
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.