Popular posts

As you may already know, the JavaScirpt CPU profiler shows how much CPU time your JavaScript is taking. The tool helps to identify jank in your code by recording exactly which functions were called and how long it took to execute.

I've generated a profile of Gmail, here is the record:

It may look like too much, but is actually quite simple.

The Heavy (Bottom Up) view will show all functions called during the time interval. This enables you to see which function has the most impact on performance. In our case, the t function took the most time - 334ms self and 641 total. Self time is the time it took to complete the current function invocation, including only the statements in the function, not including the functions that it called. Total time is the complete time the function took, including any functions that it called.

If we take the t function, we can see that the total time it took to execute is 641ms, twice as much as the self time. Let's isolate and examine it. Select the function and click on the eye button at the top. This will focus the selected function:

Altought much cleaner, we can't get much information out of it. So, let's change the view to a chart. In the upper bar, change the view from Heavy (Bottom Up) to Chart:

This is much better. It still seems like a lot, so let's see what this view is.

The Chart view provides visual representation of the CPU over time. There are two major parts:

• Overview - the upper side of the recording. The height of the bars correspond to the depth of the call stack. The higher the bar, the deeper the call stack.
• Call Stacks - in-depth view of the functions that were called during the recording. The horizontal axis the time and the vertical axis is the call stack.

So, in our case, the function invocation at ~1800ms has the deepest call stack and is probably the one that took the most time to execute. So, let's focus on that execution time only:

If we hover over the top most function, a pop-up with additional information will pop:

The pop-up provides valuable information about the function:

• Self Time - how long does it took to complete the current invocation and its statements, excluding the function it calls.
• Total Time - the time it took to complete the current invocation with any function called.
• URL - the file location and the line of the execution (since this is a chrome extension script, the file has a long cryptic like name)
• Aggregated self time - all invocations of the function, excluding the other functions called by the function
• Aggregated total time - total time of all invocations of the function, including the functions called by this function

There is another one, currently missing field called Not Optimized, which will show if the profiler detected a potential optimization for the function.

---

That is how the JavaScript CPU profiler works. It shows how long does a function took to execute. It's a great way to find deep call-stacked functions and profile your application under different scenarios.

The Chrome team is currenlty in the process of merging the JavaScript CPU Profiler and the Timeline panel into a new named panel called Performance. It looks something like this:

In the middle of the screen we can see the same execution tree, with the bottom-up and call tree. There is a new, Event Log view, which provides information for the current events triggered.

The Chrome dev team aims at extending the panel functionality even more and "depricate" the old workflow.

Personal workflow

Here is how my team and I use the profiler:

1. Know what to test - that means we start with the slowest part of the application. We make several profiles to get enough data.
2. Isolate the problem - we decouple the slow function, for example from the document load method, which gives us a better way to profile just the code we need. Later on we can refactor it to the old way.
3. Make it faster - when we have enough data and have profiled the function, we optimize it. The profiler tells us the invocation time of the function. It's up to us to investigate and refactor it.
4. Analyze again - after the optimization, we run the profiler again. That way we make sure our work is done correctly.