JavaScript Memory Management Masterclass

Video: https://www.youtube.com/watch?v=LaxbdIyBkL0

Presented at at the Google WebPerf Special (London WebPerf Group), August 26th 2014.

Efficient JavaScript webapps need to be fluid and fast. Any app with significant user interaction needs to consider how to effectively keep memory usage down because if too much is consumed, a page might be killed, forcing the user to reload it and cry in a corner.

Automatic garbage collection isn't a substitute for effective memory management, especially in large, long-running web apps. In this talk we'll walk through how to master the Chrome DevTools for effective memory management.

Learn how to tackle performance issues like memory leaks, frequent garbage collection pauses, and overall memory bloat that can really drag you down.

Transcript

1. Memory Management Masterclass @addyosmani +AddyOsmani JavaScript
2. DevTools Demos http://github.com/addyosmani/memory-mysteries Chrome Task Manager Memory Timeline Heap Profiler Object Allocation Tracker
3. The Sawtooth Curve If after a few Timeline iterations you see a sawtooth shaped graph (in the pane at the top), you are allocating lots of shortly lived objects. When the chart dips suddenly, it’s an instance when the garbage collector has run, and cleaned up your referenced memory objects. But if the sequence of actions is not expected to result in any retained memory, and the DOM node count does not drop down back to the baseline where you began, you have good reason to suspect there is a leak.
4. Memory Leak Pattern (sawtooth)
5. “Do I have a leak?” 1. Check Chrome Task Manager to see if the tab’s memory usage is growing 2. ID the sequence of actions you suspect is leaking 3. Do a Timeline recording and perform those actions 4. Use the Trash icon to force GC. If you don’t objects will be alive in memory until the next GC cycle. 5. If you iterate and see a Sawtooth curve, you’re allocating lots of short life objects. If the sequence of actions is not expected to retain memory and your DOM node count doesn’t drop - you may have a leak. 6. Use the Object Allocation Tracker to narrow down the cause of the leak. It takes heap snapshots periodically through the recording.
6. V8’s Hidden Classes V8’s optimizing compiler makes many assumptions about your code. Behind the scenes, it creates hidden classes representing objects. Using these hidden classes, V8 works much faster. If you delete properties, these assumptions may no longer be valid and code can be de-optimized slowing it down. That said, delete has a purpose in JS and is used in plenty of libraries. The takeaway is to avoid modifying the structure of hot objects at runtime. Engines like V8 can detect such “hot” objects and attempt to optimize them.
7. var o = {x: “y”}; delete o.x; o.x; // undefined var o = {x: “y”}; o = null; o.x; // TypeError Accidental de-optimization Take care with the delete keyword “o” becomes a SLOW object. It’s better to set “o” to “null”. Only when the last reference to an object is removed does that object get eligible for collection.
8. function FastPurchase(units, price) { this.units = units; this.price = price; this.total = 0; this.x = 1; } var fast = new FastPurchase(3, 25); function SlowPurchase(units, price) { this.units = units; this.price = price; this.total = 0; this.x = 1; } var slow = new SlowPurchase(3, 25); //x property is useless //so I delete it delete slow.x; Fast object Slow object “fast” objects are faster “slow” should be using a smaller memory footprint than “fast” (1 less property), shouldn”t it?
9. Reality: “Slow” uses 15 times more memory
10. Closures Closures are powerful. They enable inner functions to retain access to an outer function’s variables even after the outer function returns. Unfortunately, they’re also excellent at hiding circular references between JavaScript objects and DOM objects. Make sure to understand what references are retained in your closures. The inner function may need to still access all variables from the outer one, so as long as a reference to it exists, variables from the outer function can’t be GC’d and continue to consume memory after it’s done invoking.
11. var a = function () { var largeStr = new Array(1000000).join('x'); return function () { return largeStr; }; }(); var a = function () { var smallStr = 'x', largeStr = new Array(1000000).join('x'); return function (n) { return smallStr; }; }(); var a = (function() { // `a` will be set to the return of this function var smallStr = 'x', largeStr = new Array(1000000).join('x'); return function(n) { // which is another function; creating a closure eval(''); return smallStr; }; }()); Closures Closures can be a source of memory leaks too. Understand what references are retained in the closure.
12. DOM Leaks DOM leaks usually occur when an element gets appended to the DOM, additional elements are appended to the first element and then the original element is removed from the DOM without removing the secondary elements. In the next example, #leaf maintains a reference to its parentNode and recursively maintains references up to #tree. It’s only when leafRef is nullified is the entire tree under #tree a candidate to be garbage collected.
13. var select = document.querySelector; var treeRef = select("#tree"); var leafRef = select("#leaf"); var body = select("body"); body.removeChild(treeRef); //#tree can't be GC yet due to treeRef //let’s fix that: treeRef = null; //#tree can't be GC yet, due to //indirect reference from leafRef leafRef = null; //NOW can be #tree GC DOM Leaks. When is #tree GC’d?
14. for (var i = 0; i < 90000; i++) { var buggyObject = { callAgain: function() { var ref = this; var val = setTimeout(function() { ref.callAgain(); }, 90000); } } buggyObject.callAgain(); buggyObject = null; } Timers Timers are a common source of memory leaks. Anything you’re repetitively doing in a timer should ensure it isn’t maintaining refs to DOM objects that could accumulate leaks if they can be GC’d. If we run this loop.. This introduces a memory leak:
15. ES6 WeakMaps WeakMaps help us avoid memory leaks by holding references to properties weakly. If a WeakMap is the only objects with a reference to another object, the GC may collect the referenced object. In the next example, Person is a closure storing private data as a strong reference. The garbage collector can collect an object if there are only weak or no references to it. WeakMaps hold keys weakly so the Person instance and its private data are eligible for garbage collection when a Person object is no longer referenced by the rest of the app.
16. var Person = (function() { var privateData = new WeakMap(); function Person(name) { privateData.set(this, { name: name }); } Person.prototype.getName = function() { return privateData.get(this).name; }; return Person; }()); ES6 WeakMaps var Person = (function() { var privateData = {}, // strong reference privateId = 0; function Person(name) { Object.defineProperty(this, "_id", { value: privateId++ }); privateData[this._id] = { name: name }; } Person.prototype.getName = function() { return privateData[this._id].name; }; return Person; }()); Avoid memory leaks by holding refs to properties weakly.
17. Cheat sheet
18. cheats?!
19. Design first. Code from the design. Then profile the result.
20. Premature optimization is the root of all evil. Donald Knuth Optimize at the right time.
21. Memory Checklist
22. • Is my app using too much memory? Memory Checklist Timeline memory view and Chrome task manager can help you identify if you’re using too much memory. Memory view can track the number of live DOM nodes, documents and JS event listeners in the inspected render process.
23. • Is my app using too much memory? • Is my app free of memory leaks? Memory Checklist The Object Allocation Tracker can help you narrow down leaks by looking at JS object allocation in real-time. You can also use the heap profiler to take JS heap snapshots, analyze memory graphs and compare snapshots to discover what objects are not being cleaned up by garbage collection.
24. • Is my app using too much memory? • Is my app free of memory leaks? • How frequently is my app forcing garbage collection? Memory Checklist If you are GCing frequently, you may be allocating too frequently. The Timeline memory view can help you identify pauses of interest.
25. • Avoid long-lasting refs to DOM elements you no longer need • Avoid circular object references • Use appropriate scope • Unbind event listeners that aren’t needed anymore • Manage local cache of data. Use an aging mechanism to get rid of old objects. Good rules to follow
26. V8 Deep Dive.
27. Why does #perfmatter?
28. Longer battery life Smoother interactions Apps can live longer Silky smooth apps.
29. Nothing is free. You will always pay a price for the resources you use. Tools > Task Manager
30. JavaScript Execution Time 50-70% of time in V8 Popular sites 20-40% of time in V8 apps
31. Workload for a frame: 16ms to do everything.
32. JANK Miss it and you’ll see...
33. Blow memory & users will be sad.
34. Performance vs. Memory So what? You've got 32GB on your machine! Yeah, but my grandma's Chromebook only has 4GB. #stillSad My app’s tab is using a gig of RAM. #worstDayEver When it comes down to the age-old performance vs. memory tradeoff, we usually opt for performance.
35. Memory management basics
36. • What types of values are there? • How are values organized in memory? • What is garbage? • What is a leak? Core Concepts With thanks to John Mccutchan & Loreena Lee
37. • boolean ◦ true or false • number ◦ double precision IEEE 754 number ◦ 3.14159 • string ◦ UTF-16 string ◦ “Bruce Wayne” • objects ◦ key value maps Four primitive types Always leafs or terminating nodes.
38. object[key] = value; An object. Any variable type String only
39. Think of memory as a graph
40. The value graph Root Node Object Node Scalar Node The graph starts with a root. Root could be browser “window” or Global object of a Node module. You don’t control how this root object is GC.
41. A value's retaining path(s)
42. Removing a value from the graph
43. What is garbage? • Garbage: All values which cannot be reached from the root node.
44. 1. Find all live values 2. Return memory used by dead values to system What is garbage collection?
45. A value's retained size
46. A value's retained size
47. A value's retained size
48. What is a memory leak?
49. Gradual loss of available computer memory When a program repeatedly fails to return memory obtained for temporary use.
50. • A value that erroneously still has a retaining path ◦ Programmer error Leaks in JavaScript email.message = document.createElement("div"); display.appendChild(email.message); JavaScript
51. Leaking DOM Node email message Div Node Child Node display Child Node Child Node Native Reference
52. Leaks in JavaScript // ... display.removeAllChildren(); JavaScript Are all the div nodes actually gone?
53. Leaking DOM Node email message Div Node display Whoops. We cached a reference from the message object to the div node. Until the email is removed, this div node will be pinned in memory and we’ve leaked it.
54. • Values are organized in a graph • Values have retaining path(s) • Values have retained size(s) Memory Management Basics
55. V8 memory management
56. • Every call to new or implicit memory allocation ◦ Reserves memory for object ◦ Cheap until... • Memory pool exhausted ◦ Runtime forced to perform a garbage collection ◦ Can take milliseconds (!) • Applications must be careful with object allocation patterns ◦ Every allocation brings you closer to a GC pause Where is the cost in allocating memory?
57. Young generation Old generation
58. • Generational ◦ Split values between young and old ◦ Overtime young values promoted to old How does V8 manage memory? Young Values Old Values Long Lived Values By young and old we mean how long has the JS value existed for. After a few garbage collections, if the value survives (i.e there’s a retaining path) eventually it gets promoted to the old generation.
59. • Young Generation ◦ Fast allocation ◦ Fast collection ◦ Frequent collection How does V8 manage memory? Young Values DevTools Timeline shows the GC event on it. Below is a young generation collection.
60. • Old Generation ◦ Fast allocation ◦ Slower collection ◦ Infrequently collected How does V8 manage memory? Old Values • Parts of collection run concurrently with mutator ◦ Incremental Marking • Mark-sweep ◦ Return memory to system • Mark-compact ◦ Move values Some of the old generation’s collection occurs in parallel with your page’s execution.
61. • Why is collecting the young generation faster ◦ Cost of GC is proportional to the number of live objects How does V8 manage memory? Young Generation Collection Old Generation Collection High death rate (~80%) After GC, most values in the young generation don’t make it. They have no retaining path because they were used briefly and they’re gone.
62. Young Generation In Action To Space From Space Used during GC Values allocated from here
63. Young Generation In Action Unallocated memory From Space Assume the To Space started off empty and your page starts allocating objects..
64. Young Generation In Action A Unallocated memory From Space Allocate A
65. Young Generation In Action A Unallocated memory From Space B Allocate B
66. Young Generation In Action A Unallocated memory From Space B C Allocate C
67. Unallocated memory Young Generation In Action A D From Space B C Allocate D Until this point, everything has been fast. There’s been no interruption in your page’s execution.
68. Young Generation In Action A D From Space B C E Not enough room for E Then we do new E() and..it’s too big. We moved closer to this GC pause and we’ ve actually just triggered it.
69. Unallocated memory Young Generation In Action A D From Space B C Collection Triggered Page paused So, E doesn’t happen. It’s kind of paused. The page is paused, everything halts and the collection is triggered.
70. To Space Unallocated memory Young Generation In Action A D B C From and To space are swapped
71. To Space Unallocated memory Young Generation In Action A D B C Live Values are found Labels are flipped internally and then the live values are found.
72. To Space Unallocated memory Young Generation In Action A D B C A and C are marked. B and D are not marked so they’re garbage. They’re not going anywhere.
73. To Space Unallocated memory Young Generation In Action A D B C Live Values Copied This is when the live values are copied from the From Space to the To Space.
74. From Space To Space Young Generation In Action A C Unallocated memory Unallocated memory A D B C So here we’ve done the copy. We’ve done the collection. Copied the live objects from one semispace to the next.
75. From Space To Space Young Generation In Action A C Unallocated memory There’s no other work done to it. It’s just ready for use the next time there’s a collection that needs to happen.
76. From Space To Space Young Generation In Action A C Unallocated memory E Allocate E At this point, your page is resumed and the object E is allocated.
77. • Each allocation moves you closer to a collection ◦ Not always obvious when you are allocating • Collection pauses your application ◦ Higher latency ◦ Dropped frames ◦ Unhappy users How does V8 manage memory?
78. Remember: Triggering a collection pauses your app.
79. Performance Tools
80. performance.memory Great for field measurements.
81. the amount of memory (in bytes) that the JavaScript heap is limited to performance.memory jsHeapSizeLimit
82. the amount of memory (in bytes) that the JavaScript heap is limited to the amount of memory (in bytes) currently being used performance.memory jsHeapSizeLimit totalJSHeapSize
83. the amount of memory (in bytes) that the JavaScript heap is limited to the amount of memory (in bytes) currently being used the amount of memory (in bytes) that the JavaScript heap has allocated, including free space performance.memory jsHeapSizeLimit totalJSHeapSize usedJSHeapSize
84. Chrome DevTools
85. DevTools Memory Timeline
86. Force GC from DevTools Snapshots automatically force GC. In Timeline, it can be useful to force a GC too using the Trash can.
87. Memory distribution Taking heap snapshots
88. Results Reachable JavaScript Objects
89. Switching between views Summary groups by constructor name Comparison compares two snapshots Containment bird’s eye view of the object structure
90. Understanding node colors yellow red Object has a JavaScript reference on it Detached node. Referenced from one with a yellow background.
91. Reading results Summary
92. Distance from the GC root. Distance If all objects of the same type are at the same distance and a few are at a bigger distance, it’s worth investigating. Are you leaking the latter ones?
93. Memory used by objects and the objects they are referencing. Retained memory
94. Size of memory held by object Shallow size Even small objects can hold large amounts of memory indirectly by preventing other objects from being disposed.
95. All objects created with a specific constructor. Constructor
96. Information to understand why the object was not collected. Object’s retaining tree
97. Tip: It helps to name functions so you can easily find them in the snapshot. Closures
98. function createLargeClosure() { var largeStr = new Array(1000000).join('x'); var lC = function() { //this IS NOT a named function return largeStr; }; return lC; } function createLargeClosure() { var largeStr = new Array(1000000).join('x'); var lC = function lC() { //this IS a named function return largeStr; }; return lC; } app.js
99. Profiling Memory Leaks
100. Three snapshot technique retired
101. What do we expect? New objects to be constantly and consistently collected.
102. Start from a steady state. Checkpoint 1 We do some stuff. Checkpoint 2 We repeat the same stuff. Checkpoint 3
103. Again, what do we expect? All new memory used between Checkpoint 1 and Checkpoint 2 has been collected. New memory used between Checkpoint 2 and Checkpoint 3 may still be in use in Checkpoint 3.
104. The Steps • Open DevTools • Take a heap snapshot #1 • Perform suspicious actions • Take a heap snapshot #2 • Perform same actions again • Take a third heap snapshot #3 • Select this snapshot, and select • "Objects allocated between Snapshots 1 and 2"
106. Evolved memory profiling
107. Object Allocation Tracker Record Heap Allocations
109. Object Allocation Tracker The object tracker combines the detailed snapshot information of the heap profiler with the incremental updating and tracking of the Timeline panel. Similar to these tools, tracking objects’ heap allocation involves starting a recording, performing a sequence of actions, then stopping the recording for analysis. The object tracker takes heap snapshots periodically throughout the recording and one final snapshot at the end of the recording. The heap allocation profile shows where objects are being created and identifies the retaining path.
111. blue bars grey bars memory allocations. Taller = more memory. deallocated
112. Adjustable timeframe selector
113. Heap contents
114. Allocation Stack Traces (New)
115. DevTools Settings > Profiler > Record Heap Allocation Stack Traces
116. DevTools Settings > Profiler > Record Heap Allocation Stack Traces
117. Visualize JS processing over time
118. JavaScript CPU Profile (top down) Shows where CPU time is statistically spent on your code.
119. Select “Chart” from the drop-down
121. Flame Chart View Visualize JavaScript execution paths
122. The Flame Chart The Flame Chart provides a visual representation of JavaScript processing over time, similar to those found in the Timeline and Network panels. By analyzing and understanding function call progression visually you can gain a better understanding of the execution paths within your app. The height of all bars in a particular column is not significant, it simply represents each function call which occurred. What is important however is the width of a bar, as the length is related to the time that function took to execute.
123. Visualize profiler data against a time scale Visualize JavaScript execution paths
124. Is optimization worth the effort?
125. GMail’s memory usage (taken over a 10 month period) Memory leak fixes start to roll out Chrome GC regressions 2012 MB x 2x 3x 4x median 90th %ile 95th %ile 99th %ile
126. Through optimization, we reduced our memory footprint by 80% or more for power-users and 50% for average users. Loreena Lee, GMail
127. Resources
128. Official Chrome DevTools docs devtools.chrome.com
129. V8 Performance & Node.js https://thlorenz.github.io/v8-perf/
130. Writing Memory-efficient JavaScript http://www.smashingmagazine.com/2012/11/05/writing-fast- memory-efficient-javascript/
131. Fixing JS Memory leaks in Drupal’s editor https://www.drupal.org/node/2159965
132. Avoiding JS memory leaks in Imgur http://imgur.com/blog/2013/04/30/tech-tuesday-avoiding-a-memory- leak-situation-in-js
133. StrongLoop: Memory profiling with DevTools http://strongloop.com/strongblog/node-js-performance-tip-of-the- week-memory-leak-diagnosis/
134. Ask yourself these questions: • How much memory is your page using? • Is your page leak free? • How frequently are you GCing? Checklist
135. Chrome DevTools • window.performance.memory • Timeline Memory view • Heap Profiler • Object Allocation Tracker Know Your Arsenal.
139. #perfmatters Thank you! +AddyOsmani @addyosmani