I am sure every programmer is quite familiar with such situations: you are bursting with pride and self-content because your app is finally running without errors. You try it out on a mobile device for the first time, and you are thoroughly disappointed to realize that the performance of your masterpiece is just awful …
Then it is just about time for some profiling. This blog post will show you how profiling a JavaScript application can easily be done using Firebug’s Profiler.

Alternative Profiling Tools

Although many other browsers provide built-in profiling tools (such as Chrome, Internet Explorer or Safari), I liked Firebug’s Profiler best for its highly detailed profiling report and its way of presenting the results so that you get the most important information at one glance.

How to use the profiler

To start using Firebug’s Profiler, you need to open Firebug. Select the Console tab and click on „Profile“. The profiler is running now and observing all your JavaScript activity, making statistics about time consumption.

starting the firefox profiler

All you need to do now is trigger some activity. I am having performance issues with searching for a particular entry in a table in my app. So I enter a search term, start the search and wait until the search results are displayed. Then I click „Profile“ again in order to stop the Profiler. Firebug now opens a huge table (well, that actually depends on the complexity of your code…) containing the profiling results. Here is an excerpt from the table I got:

profiling report

How to read the results

The great art now lies in correctly interpreting the results in order to know which part of the code is causing the trouble. Therefore it is vital to know which information is contained in the report:

In the top left corner, the profiling report specifies the total amount of time for executing the activity, as well as the total number of function calls that were involved. The table below lists every function that was called during the sort. The columns provide the following information:

  • Function: the name of the invoked function
  • Calls: how often has this function been called?
  • Percent: the percentage of time this function consumed in relation to all other functions within the sorting
  • Own time: total time spent within the function (summary of all calls)
  • Time: total time spent within the function (summary of all calls); the difference to ‚own time‘ is that ‚time‘ also includes the time spent within functions that were called by that function
  • Avg: average time for one call of the function
  • Min: minimal time for one call of the function
  • Max: maximal time for one call of the function
  • File: the name of the file in which the function is located and the line number of the function; a link leads directly to the file

By default the table is sorted so that those functions accounting for the highest percentage are listed first. Thus your culprits are easy to spot!

Having conducted the profiling and identified the functions responsible for the high time consumption, we need to start to analyze those functions and think of ways to improve their performance. How I used the profiling report to improve the performance of my search I will describe in a following blog post.