JavaScript 内存管理


Memory Management Masterclass @addyosmani +AddyOsmani JavaScript DevTools Demos http://github.com/addyosmani/memory-mysteries Chrome Task Manager Memory Timeline Heap Profiler Object Allocation Tracker 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. Memory Leak Pattern (sawtooth) “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. 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. 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. 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? Reality: “Slow” uses 15 times more memory 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. 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. 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. 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? 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: 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. 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. Cheat sheet cheats?! Design first. Code from the design. Then profile the result. Premature optimization is the root of all evil. Donald Knuth Optimize at the right time. Memory Checklist ● 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. ● 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. ● 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. ● 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 V8 Deep Dive. Why does #perfmatter? Longer battery life Smoother interactions Apps can live longer Silky smooth apps. Nothing is free. You will always pay a price for the resources you use. Tools > Task Manager JavaScript Execution Time 50-70% of time in V8 Popular sites 20-40% of time in V8 apps Workload for a frame: 16ms to do everything. JANK Miss it and you’ll see... Blow memory & users will be sad. 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. Memory management basics ● 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 ● 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. object[key] = value; An object. Any variable type String only Think of memory as a graph 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. A value's retaining path(s) Removing a value from the graph What is garbage? ● Garbage: All values which cannot be reached from the root node. 1. Find all live values 2. Return memory used by dead values to system What is garbage collection? A value's retained size A value's retained size A value's retained size What is a memory leak? Gradual loss of available computer memory When a program repeatedly fails to return memory obtained for temporary use. ● A value that erroneously still has a retaining path ○ Programmer error Leaks in JavaScript email.message = document.createElement("div"); display.appendChild(email.message); JavaScript Leaking DOM Node email message Div Node Child Node display Child Node Child Node Native Reference Leaks in JavaScript // ... display.removeAllChildren(); JavaScript Are all the div nodes actually gone? 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. ● Values are organized in a graph ● Values have retaining path(s) ● Values have retained size(s) Memory Management Basics V8 memory management ● 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? Young generation Old generation ● 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. ● 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. ● 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. ● 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. Young Generation In Action To Space From Space Used during GC Values allocated from here Young Generation In Action Unallocated memory From Space Assume the To Space started off empty and your page starts allocating objects.. Young Generation In Action A Unallocated memory From Space Allocate A Young Generation In Action A Unallocated memory From Space B Allocate B Young Generation In Action A Unallocated memory From Space B C Allocate C 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. 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. 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. To Space Unallocated memory Young Generation In Action A DB C From and To space are swapped To Space Unallocated memory Young Generation In Action A DB C Live Values are found Labels are flipped internally and then the live values are found. To Space Unallocated memory Young Generation In Action A DB C A and C are marked. B and D are not marked so they’re garbage. They’re not going anywhere. To Space Unallocated memory Young Generation In Action A DB C Live Values Copied This is when the live values are copied from the From Space to the To Space. From Space To Space Young Generation In Action A C Unallocated memory Unallocated memoryA DB C So here we’ve done the copy. We’ve done the collection. Copied the live objects from one semispace to the next. 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. From Space To Space Young Generation In Action A C Unallocated memoryE Allocate E At this point, your page is resumed and the object E is allocated. ● 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? Remember: Triggering a collection pauses your app. Performance Tools performance.memory Great for field measurements. the amount of memory (in bytes) that the JavaScript heap is limited to performance.memory jsHeapSizeLimit 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 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 Chrome DevTools DevTools Memory Timeline Force GC from DevTools Snapshots automatically force GC. In Timeline, it can be useful to force a GC too using the Trash can. Memory distribution Taking heap snapshots Results Reachable JavaScript Objects Switching between views Summary groups by constructor name Comparison compares two snapshots Containment bird’s eye view of the object structure Understanding node colors yellow red Object has a JavaScript reference on it Detached node. Referenced from one with a yellow background. Reading results Summary 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? Memory used by objects and the objects they are referencing. Retained memory 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. All objects created with a specific constructor. Constructor Information to understand why the object was not collected. Object’s retaining tree Tip: It helps to name functions so you can easily find them in the snapshot. Closures 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 Profiling Memory Leaks Three snapshot technique retired What do we expect? New objects to be constantly and consistently collected. Start from a steady state. Checkpoint 1 We do some stuff. Checkpoint 2 We repeat the same stuff. Checkpoint 3 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. 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" Evolved memory profiling Object Allocation TrackerRecord Heap Allocations 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. blue bars grey bars memory allocations. Taller = more memory. deallocated Adjustable timeframe selector Heap contents Allocation Stack Traces (New) DevTools Settings > Profiler > Record Heap Allocation Stack Traces DevTools Settings > Profiler > Record Heap Allocation Stack Traces Visualize JS processing over time JavaScript CPU Profile (top down) Shows where CPU time is statistically spent on your code. Select “Chart” from the drop-down Flame Chart View Visualize JavaScript execution paths 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. Visualize profiler data against a time scale Visualize JavaScript execution paths Is optimization worth the effort? 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 Through optimization, we reduced our memory footprint by 80% or more for power-users and 50% for average users. Loreena Lee, GMail Resources Official Chrome DevTools docs devtools.chrome.com V8 Performance & Node.js https://thlorenz.github.io/v8-perf/ Writing Memory-efficient JavaScript http://www.smashingmagazine.com/2012/11/05/writing-fast- memory-efficient-javascript/ Fixing JS Memory leaks in Drupal’s editor https://www.drupal.org/node/2159965 Avoiding JS memory leaks in Imgur http://imgur.com/blog/2013/04/30/tech-tuesday-avoiding-a-memory- leak-situation-in-js StrongLoop: Memory profiling with DevTools http://strongloop.com/strongblog/node-js-performance-tip-of-the- week-memory-leak-diagnosis/ Ask yourself these questions: ● How much memory is your page using? ● Is your page leak free? ● How frequently are you GCing? Checklist Chrome DevTools ● window.performance.memory ● Timeline Memory view ● Heap Profiler ● Object Allocation Tracker Know Your Arsenal. #perfmatters Thank you! +AddyOsmani @addyosmani
还剩138页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

kpl64

贡献于2014-09-08

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf