Profiling JavaScript 101 Using IE9 Developer Tools

Lately I’m involved in a very interesting project which suffer from JavaScript performance issues in old browsers. The main “pain” in the project is the need to support IE8 which is used by many of the client’s users. I’ve got a call to come and help in the process of tuning the application and decided to share some tips of how I profiled the application and found some of the bottlenecks in the application JavaScript execution. Those bottlenecks were handled by the development team very fast and the application’s execution is becoming much better. Since the main problems were mainly in IE8 then I used IE Developer Tools in the process and not FireBug.

Starting a Profiling Session

The first thing that you’ll want to do when you profile JavaScript is to setup your environment. First open the relevant web page in IE and press F12 in order to open the IE Developer Tools. In the developer tools, change the Browser Mode and Document Mode to IE8 and IE8 standards respectfully like in this figure:

Now open the Profiler tab and press the Start profiling button to enable profiling:

Then, press F5 to refresh the page and after the page finish to run press the Stop profiling and get the profiling report.

Reading the Profiling Report

When you have the report here are things that you need to pay attention while figuring out the information you got:

• Count – when the count of function calls is very big (for example the amount of RegExp.exec in the figure) that might indicate that you have a problem. Combining the count with the Exclusive time might help to find bugs in the JavaScript use.
  
  At the client there were a lot of calls to jQuery’s CLASS method. After figuring this out and seeing that the Exclusive execution time was very high I debugged the CLASS method and got the stack call to figure that there was a bug in an application function. Fixing the function helped to improve performance.
  
  There are times that you will find that there are functions that got call in very similar numbers. This might indicate that they were called inside the same function. This is very inaccurate measurement but it might help sometimes.  
• Inclusive time – this is the execution time of a method and all of its children. Here you’ll find the methods that executed for very long time. This measurement can help to figure out bottlenecks.
  
  At the client we found out that Telerik’s RadGrid control and its inner LoadSod function are one of the bottlenecks in the application. I’m not saying here that the control has bad performance (on the contrary the control is fast) but only that in the application the control is one of the bottlenecks. I found a way to improve a little the control’s performance but the improvement was very negligible (50 milliseconds) so we dropped it.
• Exclusive time – this is the amount of time that is spent in the function itself. Here you can track very long running functions and then debug them to understand why the run for so long.
  
  At the client we found a bug in one of the functions that was called with setTimeout very often and damaged the performance of the application.

Another way to use the report is the Call tree report that pack all the execution of functions in a tree view:

Here you can drill down the execution stack and figure out using the previous measurements how the application operate.

Tip: pressing double click on a function line in the report can take you to the JavaScript source file (if exists). Then you can set a break point and debug the function call.

Summary

Profiling JavaScript isn’t as simple as it sound. Using profiling tools like in IE Devloper Tools (which I used because IE8 was giving hard times to the client) or FireBug can help to simplify this matter a lot. Knowing how to read the reports will probably help to fine tuned the code you wrote.