Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Profiling JavaScript 101 Using IE9 Developer Tools

, 15 Aug 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
Profiling JavaScript 101: Using IE9 Developer Tools.

Profiling JavaScript 101 Using IE9 Developer Tools

Profiling JavaScript 101 Using IE9 Developer ToolsLately 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:IE9 Developer Tools

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

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

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:
Call 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Gil Fink
Technical Lead sparXys
Israel Israel
Gil Fink is a web development expert and ASP.Net/IIS Microsoft MVP. He is the founder and owner of sparXys. He is currently consulting for various enterprises and companies, where he helps to develop Web and RIA-based solutions. He conducts lectures and workshops for individuals and enterprises who want to specialize in infrastructure and web development. He is also co-author of several Microsoft Official Courses (MOCs) and training kits, co-author of "Pro Single Page Application Development" book (Apress) and the founder of Front-End.IL Meetup. You can read his publications at his website: http://www.gilfink.net
Follow on   Twitter   Google+   LinkedIn

Comments and Discussions

 
GeneralGood too know, but PinmemberWonde Tadesse15-Aug-11 14:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.141015.1 | Last Updated 15 Aug 2011
Article Copyright 2011 by Gil Fink
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid