JavaScript memory analytics for Chrome developer tools

Although JavaScript uses garbage collection for automatic memory management, effective (effective) memory management is still important. In this article we will explore memory issues in the analysis of JavaScript Web applications. When learning about features, be sure to try the relevant cases to improve your understanding of how these tools work in practice. Please read the Memory 101 page to help you familiarize yourself with the terminology used in this article. Note: Some of the features we're going to use are currently available only for Chrome Canary browsers. We recommend using this version to get the best tools to analyze your application's memory problems.

The question you need to think about

Overall, when you think you're experiencing a memory leak, you need to think about three questions:

• does my page occupy too much memory? - Timeline Memory Viewing tool (Timeline memories view) and Chrome task management (Chrome Tasks manager) can help you determine if you are using too much memory. Memory View tracks DOM node count, documents count, and JS event listener count during page rendering. As a rule of thumb: Avoid references to DOM elements that are no longer needed, remove unwanted event snooping, and keep in mind when storing chunks of data that you might not be using.
• is there a memory leak on my page? - object Assignment tracking (objects allocation Tracker) helps you locate leaks by viewing the allocation of JS objects in real time. You can also use the heap profiler to generate a JS heap snapshot to identify objects that have not been cleaned up by garbage collection by analyzing the differences between the memory graph and the comparison snapshot.
• how often is my page garbage forced collection? -If your page is garbage collected very frequently, it means that your page may be allocated too often for memory usage. The Timeline Memory viewing tool (Timeline memories view) can help you discover the pauses of interest.

Terminology and basic concepts

This section describes the common terminology used in memory analysis , which is also applicable in tools that do memory analysis for other languages. The terminology and concepts are used in the Heap Profiler UI tool and related documentation.

These can help us become familiar with how to use memory analysis tools effectively. If you've ever used something like Java,. NET and other languages such as memory analysis tools, then this will be a review.

Object Size (Sizes)

Think of memory as a chart that contains basic types (like numbers and strings) and objects (associative arrays). It may look like the graph of a series of associated points below.

There are two methods of using memory for an object:

• Direct use of the object itself
• The implicit retention of references to other objects prevents garbage collection (GC) from automatically reclaiming those objects.

When you use the heap Analyzer in Devtools (the heap Profiler, the tool used to analyze memory problems, under Devtools's "Profile" tab), you may be pleasantly surprised to find some columns that display a variety of information. Two of these are: Direct memory (shallow size) and total memory (retained size), what do they mean?

Direct memory consumption (shallow Size, excluding memory consumed by referenced objects)

This is the memory occupied by the object itself.

A typical JavaScript object would have reserved memory to describe the object and store its direct value. In general, only arrays and strings will have significant direct memory consumption (shallow Size). However, strings and arrays often store the main data part in the renderer memory, exposing only a small wrapper object to the JavaScript object stack.

Renderer memory refers to all of the memory used by the page you analyze in the process of rendering: the memory of the page itself + the JS heap in the page that is used in the memory + page triggered by the JS heap in the associated worker process (workers). However, by preventing garbage from automatically reclaiming other objects, a small object can potentially consume a lot of memory indirectly.

Occupies total memory (retained Size, including memory consumed by referenced objects)

Once an object is deleted, the dependent objects referenced by it cannot be referenced by GC root (GC root) , and the memory occupied by them is freed, and an object consumes the total memory that is occupied by those dependent objects.

GC roots are made up of controllers (handles) that are created when a reference to a JavaScript object, whether local or global, is established by the Build-in function (native code) to the V8 engine. All of these controllers can be found in GC roots (GC root) > Handle scope and gc roots >Global handlers for heap snapshots. If you do not have a deep understanding of how browsers are implemented, it may not be understandable to introduce these controllers in this article. GC Root and controller you don't need to care too much.

There are many internal GC roots that are not important to the user. There are several scenarios from an application perspective:

• Window Global Object (in all IFRAME). There is a distance field in the heap snapshot, which is the shortest path length from the window object to the corresponding object.
• The document DOM tree that consists of all the DOM nodes that the document can traverse to. Not all nodes will be referenced by the corresponding JS, but the node with JS reference will be preserved in the case of document existence.
• There are many objects that may have been created when debugging code or in Devtools console (e.g., after some code execution in the console has finished).

Note: We recommend that users do not execute code in the console or enable debug breakpoints when creating a heap snapshot.

The memory map starts with a root, possibly a browser window object or a node Global . JS Module object. How these objects are reclaimed by memory is not under the control of the user.

JavaScript memory analytics for Chrome developer tools