From de5c456ebded0e038adbf23db34cc290c8829180 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:49:24 +0100 Subject: unslug pl: move --- files/pl/tools/performance/flame_chart/index.html | 103 ++++++++++++++++++++++ files/pl/tools/performance/index.html | 97 ++++++++++++++++++++ 2 files changed, 200 insertions(+) create mode 100644 files/pl/tools/performance/flame_chart/index.html create mode 100644 files/pl/tools/performance/index.html (limited to 'files/pl/tools/performance') diff --git a/files/pl/tools/performance/flame_chart/index.html b/files/pl/tools/performance/flame_chart/index.html new file mode 100644 index 0000000000..1edebd4d01 --- /dev/null +++ b/files/pl/tools/performance/flame_chart/index.html @@ -0,0 +1,103 @@ +--- +title: Flame Chart +slug: Narzędzia/Performance/Flame_Chart +translation_of: Tools/Performance/Flame_Chart +--- +
+

The Flame Chart shows you the state of the JavaScript stack for your code at every millisecond during the performance profile.

+ +

This gives you a way to know exactly which function was executing at any point during the recording, how long it ran for, and where it was called from.

+
+ +

The Call Tree and the Flame Chart are both used to analyze your site's JavaScript, and they both use the same data: a sample of the JavaScript engine's stack, taken periodically during the recording.

+ +

But while the Call Tree organizes this data to show you where your program is spending most time in aggregate across the recording, the Flame Chart uses it to show you when in the recording particular functions are executing. Essentially it shows you the state of the call stack at any given point during the recording.

+ +

Here's a screenshot showing the Flame Chart for a section of a profile:

+ +

+ +

First of all, you'll see that, in the recording overview pane, we've selected a small slice of the recording to view in the Flame Chart. The Flame Chart displays a lot of data, so to get readable results, it's usually necessary to zoom in.

+ +

In the Flame Chart view itself, along the X-axis is time. The screenshot above covers the period from 1435ms to a little past 1465ms. Along the Y-axis are the functions on the call stack at that point in time, with the top-level at the top, and the leaf function at the bottom. Functions are color-coded to make them easier to distinguish.

+ +

This gives you a way to know exactly which function was executing at any point during the recording, how long it ran for, and where it was called from.

+ +

Zooming and panning

+ +

To work effectively with the Flame Chart, you'll need to be able to navigate it. There are two main controls you can use to navigate the Flame Chart:

+ + + + + + + + + + + + +
Zoom: increase/decrease the selected portion of the complete profile that's displayed in the Flame Chart +

1) Mouse wheel up/down in the Flame Chart.

+ +

2) Trackpad 2 fingers up/down in the Flame Chart.

+
Pan: move the selected portion of the complete profile left and right +

1) Click and drag the selected portion in the recording overview pane.

+ +

2) Click and drag anywhere in the Flame Chart.

+
+ +

{{EmbedYouTube("BzfkBRFucp8")}}

+ +

An example

+ +

To see how the Flame Chart can reveal the behavior of your program, we'll look at a simple example. We'll use the same example as in the Call Tree page: a program that compares three different sorting algorithms. There's a separate page that gives an overview of this program's structure.

+ +

We'll use the same profile file as that used in the Call Tree page. In the call tree page, we figured out that the program call graph in that profile, and the associated sample count, looked like this:

+ +
sortAll()                         //    8
+
+    -> sort()                     //   37
+
+        -> bubbleSort()           // 1345
+
+            -> swap()             //  252
+
+        -> selectionSort()        //  190
+
+            -> swap()             //    1
+
+        -> quickSort()            //  103
+
+            -> partition()        //   12
+ +

First, we'll just select the whole section in which the program was active:

+ +

+ +

At the top, colored purple, is the sortAll() call, running throughout the program from start to finish. Underneath that, colored olive-green, are the calls it's making to sort(). Underneath that, like the teeth of a comb, are all the calls being made to each sorting algorithm.

+ +

Let's zoom in:

+ +

+ +

This slice is about 140 ms long, and shows us more details of the functions being called by sort(). The sort() code is just this:

+ +
function sort(unsorted) {
+  console.log(bubbleSort(unsorted));
+  console.log(selectionSort(unsorted));
+  console.log(quickSort(unsorted));
+}
+ +

The markers labeled "bubb..." and colored olive-green are presumably bubbleSort(). The ones colored plain green are presumably the other sort functions. Even at a glance, we can see that the bubble sort blocks are much wider (of a longer duration) than the others.

+ +

We can also see some functions being called from bubbleSort(), colored purple.

+ +

Let's zoom in one more time:

+ +

+ +

This slice is about 20ms long. We can see that the purple markers underneath bubbleSort() are the calls to swap(). If you counted them all, the Call Tree view tells us that you'd see 253 of them. All the ones in this zoom are underneath bubbleSort(), but according to the Call Tree view, the profile does contain one under selectionSort().

+ +

We can also see that two of the green markers are for selectionSort() and quickSort(), but we're also seeing calls to platform (Gecko) code in between our calls to the sorting functions. It seems very likely that this is from the console.log() calls in sort().

diff --git a/files/pl/tools/performance/index.html b/files/pl/tools/performance/index.html new file mode 100644 index 0000000000..346399027f --- /dev/null +++ b/files/pl/tools/performance/index.html @@ -0,0 +1,97 @@ +--- +title: Performance +slug: Narzędzia/Performance +tags: + - NeedsTranslation + - TopicStub +translation_of: Tools/Performance +--- +

The Performance tool gives you insight into your site's general responsiveness, JavaScript and layout performance. With the Performance tool you create a recording, or profile, of your site over a period of time. The tool then shows you an overview of the things the browser was doing to render your site over the profile, and a graph of the frame rate over the profile.

+ +

You get four sub-tools to examine aspects of the profile in more detail:

+ + + +

{{EmbedYouTube("WBmttwfA_k8")}}

+ +
+

Getting started

+ +
+
+
+
UI Tour
+
+

To find your way around the Performance tool, here's a quick tour of the UI.

+
+
+
+ +
+
+
How to
+
Basic tasks: open the tool, create, save, load, and configure recordings
+
+
+
+ +
+

Components of the Performance tool

+ +
+
+
+
Frame rate
+
Understand your site's overall responsiveness.
+
Call Tree
+
Find bottlenecks in your site's JavaScript.
+
Allocations
+
See the allocations made by your code over the course of the recording.
+
+
+ +
+
+
Waterfall
+
Understand the work the browser's doing as the user interacts with your site.
+
Flame Chart
+
See which JavaScript functions are executing, and when, over the course of the recording.
+
 
+
+
+
+ +
+

Scenarios

+ +
+
+
+
Animating CSS properties
+
Uses the Waterfall to understand how the browser updates a page, and how animating different CSS properties can affect performance.
+
 
+
+
+ +
+
+
Intensive JavaScript
+
Uses the frame rate and Waterfall tools to highlight performance problems caused by long-running JavaScript, and how using workers can help in this situation.
+
+
+
+ +

 

+ +
+
+
 
+
+
+ +

 

-- cgit v1.2.3-54-g00ecf