title | description | author | ms.author | ms.topic | ms.service | ms.subservice | ms.date |
---|---|---|---|---|---|---|---|
Speed up JavaScript runtime ("Allocation sampling" profiling type) |
Identify expensive, inefficient functions by using the Memory panel of Microsoft Edge DevTools. |
MSEdgeTeam |
msedgedevrel |
conceptual |
microsoft-edge |
devtools |
05/04/2021 |
To identify expensive functions, use the Memory tool:
Record exactly which functions were called and how much memory each requires with Allocation Sampling in the Memory tool.
Visualize your profiles as a flame chart.
To use the Allocation sampling profiling type to view memory allocation by JavaScript function:
-
Open a webpage; for example, open the Example 3: Scattered objects demo in a new window or tab.
-
To open DevTools, right-click the webpage, and then select Inspect. Or, press Ctrl+Shift+I (Windows, Linux) or Command+Option+I (macOS). DevTools opens.
-
In DevTools, on the Activity Bar, select the Memory tool. If that tool isn't visible, click the More tools (
) button.
-
Select the Allocation sampling option button.
-
In the Select JavaScript VM instance section, if there is a worker on the page, you can select that as the profiling target.
-
Click the Start button.
-
On the webpage, perform actions that you want to investigate. For example, click the Create scattered objects button in the Example 3: Scattered objects webpage.
-
In the upper left of the Memory tool, click the Stop heap profiling (
) button.
A new profile is added in the Sampling profiles section in the Profiles sidebar. The profile shows a breakdown of memory allocation by function. The default view is Heavy (Bottom Up), which displays the functions that allocated the most memory at the top:
If you notice jank (interruptions of rendering) in your JavaScript, collect a Sampling Profile. Sampling Profiles show where running time is spent on functions in your page.
This section is similar to the above section, but shows a different demo webpage.
To record an allocation sampling profile:
-
Open a webpage, such as the Detached Elements demo webpage, in a new window or tab.
-
Right-click the webpage, and then select Inspect. Or, press Ctrl+Shift+I (Windows, Linux) or Command+Option+I (macOS).
DevTools opens.
-
In DevTools, in the Activity Bar, select the Memory (
) tool.
If that tab isn't visible, click the More Tools (
) button, and then select Memory. The Memory tool opens:
-
Select the Allocation sampling option button.
If the Allocation sampling option button isn't shown, because a profile is already displayed, in the upper left, click Profiles (
).
-
At the bottom of the Memory tool, click the Start button.
-
Interact with the webpage; for example, click the Fast traffic button and then the Stop button in the demo webpage. Depending on what you are trying to analyze, you can either refresh the page, interact with the page, or just let the page run.
-
In the upper left of the Memory tool, click the Stop heap profiling (
) button.
A new Profile is created in the Sampling profiles section of the Profiles list:
You can also use the Console Utilities API to record and group profiles from the command line.
When you finish recording, DevTools automatically populates the Memory panel next to the Sampling profiles list with the data from your recording.
The default view is Heavy (Bottom Up). This view allows you to review which functions had the most impact on performance and examine the requesting path for each function.
To change the sorting order, use the dropdown menu that initially says Heavy (Bottom Up):
Menuitems:
- Chart
- Heavy (Bottom Up)
- Tree (Top Down)
Chart. Displays a chronological chart of the recording:
Heavy (Bottom Up). Lists functions by impact on performance and enables you to examine the calling paths to the functions. This is the default view:
Tree (Top Down). Shows an overall picture of the calling structure, starting at the top of the call stack:
When Heavy (Bottom Up) or Tree (Top Down) is selected (not Chart), there are several buttons, that are available (not dimmed) when you select a row:
To exclude a function from your Sampling Profile, select it and then click the Exclude selected function () button. The requesting function (parent) of the excluded function (child) is charged with the allocated memory assigned to the excluded function (child).
Click the Restore all functions () button to restore all excluded functions back into the recording.
The Chart view provides a visual representation of the Sampling Profile over time.
After you record a Sampling Profile, view the recording as a flame chart by changing the sort order to Chart.
The flame chart is split into two parts:
index | Part | Description |
---|---|---|
1 | Overview | A birds-eye view of the entire recording. The height of the bars correspond to the depth of the call stack. So, the higher the bar, the deeper the call stack. |
2 | Call Stacks | This is an in-depth view of the functions that were called during the recording. The horizontal axis is time and vertical axis is the call stack. The stacks are organized top-down. So, the function on top called the one below it, and so on. |
Functions are colored randomly. There is no correlation to the colors used in the other panels. However, functions are always colored the same across invocations, so that you can observe patterns in each runtime.
A tall call stack isn't necessarily significant; it might just mean that a lot of functions were called. But a wide bar means that a function took a long time to complete, so these are candidates for optimization.
To zoom in on particular parts of the call stack, click and drag left and right across the overview. After you zoom, the call stack automatically displays the portion of the recording that you selected.
Click a function, to view it in the Sources tool.
Hover on a function to display the name and timing data:
Detail | Description |
---|---|
Name | The name of the function. |
Self size | The size of the current invocation of the function, including only the statements in the function. |
Total size | The size of the current invocation of this function and any functions that it called. |
URL | The location of the function definition in the form of base.js:261 where base.js is the name of the file where the function is defined and 261 is the line number of the definition. |
By default, the Allocation sampling profiling type only reports allocations that are still alive at the end of the recording session. Objects that are created, removed, and then garbage collected (GC'd) aren't displayed in the Memory tool when profiling using the Allocation sampling or Allocations on timeline profiling types.
You can trust the browser to clean up garbage from your code. However, it is important to consider that GC itself is an expensive operation and multiple GCs can slow down your user's experience of your website or app. When recording in the Performance tool with the Memory checkbox turned on, you can see the GC operation happen at the steep cliffs (sudden decreases) in the heap chart:
By reducing the amount of garbage your code is creating, you can reduce the cost of each individual GC and the number of GC operations.
To track objects that are discarded by garbage collection:
-
In the Memory tool, select the Allocation sampling option button.
-
Click the Include objects discarded by major GC and Include objects discarded by minor GC settings.
-
Click the Start button.
-
On the webpage, perform actions that you want to investigate.
-
Click the Stop button when you have finished all of your actions.
DevTools now tracks all of the objects that were GC'd during the recording. Use these settings to understand how much garbage your website or app is generating. The data reported by Allocation sampling will help you identify the functions that are generating the most garbage.
If you are investigating objects that were only GC'd during specific major or minor GC operations, configure the settings appropriately to track the operation you care about. To learn more about the differences between major and minor GC, see Trash talk: the Orinoco garbage collector | V8 JavaScript engine developer blog.
Note
Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons Attribution 4.0 International License. The original page is found here and is authored by Kayce Basques (Technical Writer, Chrome DevTools & Lighthouse) and Meggin Kearney (Technical Writer).
This work is licensed under a Creative Commons Attribution 4.0 International License.