Freigeben über

Introducing the IE8 Developer Tools JScript Profiler

  • Artikel

Hello! I am Sameer Chabungbam, one of the Program Managers on the JScript Team.

The recently released Beta 2 of Internet Explorer 8 contains a lot of improvements which are aimed at making developing web applications on Internet Explorer 8 easier and more productive. One of these improvements is the JScript Profiler in Developer Tools, which provides critical JScript related performance data to a web developer that helps identify and fix performance related issues. We believe the Profiler is going to be a very helpful tool to fine tune the performance of the scripts in a web application. It is lightweight, easy-to-use and provides the following features:

  • Provides performance data for JScript functions in two views:
    • Functions View – a flat listing of all the functions
    • Call Tree view – a hierarchical listing of the functions based on the call flow
  • Supports exporting the data to a file
  • Provides an inferred name for anonymous functions
  • Profiles built-in JScript functions
  • Supports multiple profile reports
  • Supports profiling across page navigation and refreshes

This post gives an overview of the Profiler and highlights some of its features. We hope you will try it out and give us your feedback.

Using the Profiler

Launch the Developer Tools in Internet Explorer 8 either by pressing F12 or selecting ‘Developer Tools’ from the Tools dropdown on the command bar. Switch to the Profiler Tab, and you can see the new Script Profiler. Click the ‘Start Profiling’ button to begin a new profiling session.

JScript Profiler Main Screen

Now, you can perform the scenario you want to profile, and JScript performance data will be collected by the profiler automatically in the background. Note that the text of the button changes to ‘Stop Profiling’ to indicate profiling is going on. To stop profiling, click the ‘Stop Profiling’ button. The profiler will process the collected performance data and display a profile report for the session just concluded.

JScript Profile Report

Viewing the Profile Report

The report presents the data in two views which can be selected from the Current View dropdown:

  • Functions view: This is a flat listing of all the functions with the corresponding performance data.
  • Call Tree view: This is a hierarchical listing of the functions based on the call execution sequence. Each node corresponds to a function and lists all the functions it called and the performance data for those calls. The Call Tree view is useful in finding the call stack trace that has the greatest performance impact in your script.

In both views, each row corresponds to a JScript function, with the various performance data in different columns. The view can be customized to show different columns. Right-click a column header and select ‘Add / Remove Columns’ to select the columns you want to view.

Call Tree with Context Menu

You can sort on any of the columns by clicking the corresponding column headers or by selecting the column from the ‘Sort By’ menu items in the right-click context menu.

The available columns are:

  • Function: The name of the function
  • Count: The total number of calls made to this function
  • Inclusive Time (ms): The time spent in this function and its children in milliseconds
  • Inclusive Time %: The percentage of time spent in this function and its children
  • Exclusive Time (ms): The time spent in this function in milliseconds
  • Exclusive Time %: The percentage of time spent in this function
  • Avg Time (ms): The average time spent in this function and its children in milliseconds
  • Max Time (ms): The maximum time spent in this function and its children in milliseconds
  • Min Time (ms): The minimum time spent in this function and its children in milliseconds
  • URL: The URL of the source file where this function is defined
  • Line Number: The line number of the beginning of this function in the source file

Double-click a row to view the source code definition of the corresponding function in the Script Tab. This is available only if the performance data collects the URL information and the source file is currently loaded in the Script Tab. You need to enable script debugging in Internet Explorer for the profiler to collect the URL information. [Note: You can enable script debugging from the Tools > Internet Options > Advanced Tab.] Function Source View

Exporting Data

Sometimes, we may want to analyze the profile report further, create graphs, or share it with another application. To facilitate this, the Profiler allows the data to be exported to a file in a Comma Separated Values (CSV) format. The data can then be opened in other applications (like Microsoft® Office Excel®) and can be shared. Simply click the ‘Export Data’ button Export Data Icon and give a filename to save the profile data of the current report to a file. Note that presently only the Functions view is exported and not the Call Tree view.

Inferred name

In Javascript, the function name is optional. You can define a function (called anonymous function) with no name. In practice, this is quite common. Many real-world Javascript functions are defined in the context of an object literal, and more often than not, these are anonymous. This presents a problem in the profile report. When we have multiple anonymous entries, the only way to differentiate the anonymous functions is to look up the actual source definition of the functions from the URL and Line number information. This is far from being convenient and makes the profile report hard to read and confusing.

To overcome this problem, the JScript profiler tries to infer a name for each anonymous function based on the context where the function is defined. Let me illustrate how this works with the following example:

var Shape = {
    Area : function () { . . . } // anonymous function 1
};
Foo = function () { . . . } // anonymous function 2

When we profile this code, these functions will show up in the report as “Area” and “Foo” respectively, instead of both being listed as anonymous functions. This way, you can quickly identify which function is being referred to in the profile report without having to open the source code. The heuristic logic used to infer the name is simple enough to limit the performance overhead. In some cases, this might fail to infer a name, in which case, the function is listed with the special name “[Anonymous]”.

We hope the profiler comes handy when improving Javascript performance of your web applications in Internet Explorer. We look forward to your feedback.

Thanks!

Sameer Chabungbam
Program Manager

Comments

  • Anonymous
    September 11, 2008
    PingBack from http://blog.a-foton.ru/2008/09/introducing-the-ie8-developer-tools-jscript-profiler/

  • Anonymous
    September 11, 2008
    The comment has been removed

  • Anonymous
    September 11, 2008
    Next IE feature's would be to use smartscreen filter to mark Live search links with icon if it's safe or malicious site. If that is possible to do.

  • Anonymous
    September 11, 2008
    The comment has been removed

  • Anonymous
    September 11, 2008
    Just notice that I can't delete website using organize favorites. I click delete button and no deletion at all, even when right clicking a website and selecting delete on context menu

  • Anonymous
    September 11, 2008
    Wow.  This is worth so much to me as a developer I can only say thanks.  My family just heard me utter something for the first time, "Internet Explorer just got really cool."  This helps me maximize the efficiency of my web-based application code and that's plain awesome.

  • Anonymous
    September 11, 2008
    I think that strong Javascript debugger is very necessary tool. I have never found the suitable one. I truly hope that JScript Profiler will help me quickly to improve web pages.

  • Anonymous
    September 11, 2008
    This is a very nice feature, but to me it seems more important to get IE's performance into the same league as other modern browsers first, before expecting developers to put extra effort fine tuning their scripts for IE with this tool. https://bugzilla.mozilla.org/show_bug.cgi?id=424715#c9 is one extreme example of how far behind IE8's performance remains, but IE is still significantly behind in most benchmarks I have seen.

  • Anonymous
    September 11, 2008
    there is any chance to have this on previous version of IE? Like 7 or even 6?

  • Anonymous
    September 11, 2008
    @Staicu Ionut, come on you already know the answer to that

  • Anonymous
    September 12, 2008
    What happened to the plan to combine the JScript engine in IE with the .NET CLR?  I'm sure I read that this was on the cards for IE8 release, I think when Mozilla paid a visit to your offices.

  • Anonymous
    September 12, 2008
    This is an awesome feature - nice work!

  • Anonymous
    September 12, 2008
    Nice job coming up with Firebug, guys.

  • Anonymous
    September 12, 2008
    Great! Only one thing missing for me. Just need support to monitor XHR like firebug. Then I think it will be feature complete.

  • Anonymous
    September 12, 2008
    The comment has been removed

  • Anonymous
    September 12, 2008
    Replace the safety Menu button with a split button to quickly access the InPrivate browsing.

  • Anonymous
    September 12, 2008
    The comment has been removed

  • Anonymous
    September 12, 2008
    @Chris The profiler shows the result as the script is executed on IE8. This is irrespective of the IE7 mode.  Thanks for the suggestion - it is a good feedback!

  • Anonymous
    September 12, 2008
    Earlier i post about program taking over IE 8 search. How about a option to prevent a program changing search provider.

  • Anonymous
    September 12, 2008
    @Chris: For monitoring XHR traffic, have you looked at Fiddler?  http://www.fiddler2.com

  • Anonymous
    September 12, 2008
    It would be great somewhere to compare/contrast what InPrivate does vs some of the interpretations people have put on it. The help files and blog posts are clear and accurate on what InPrivate DOES do, but for the less careful readers, what it DOESN'T do might also be good to say. There are two main alternate scenarios that people seem to be thinking of in blog comments:

  • Guest Mode, where someone is using your PC temporarily and you don't want them using your cookies or changing your setting.  Easiest answer here seems to be letting them use a Guest user account, that's much more secure!
  • Anonymous browsing, where websites cannot track the user.  This would require something like Tor to anonymise IP addresses, as well as blocking by the browser. InPrivate browsing seems thought out smartly, better IMHO than Chrome which gives ignorant users a false illusion of Anonymous Browsing, but would be great to get extra clarification. Thanks guys, loving using IE8 it's a huge leap forward and beats the competition in many ways.

  • Anonymous
    September 12, 2008
    @Private One "InPrivate browsing seems thought out smartly, better IMHO than Chrome which gives ignorant users a false illusion of Anonymous Browsing, but would be great to get extra clarification." How about reading what's written in a newly opened Incognito tab, in Chrome?... Wait, never mind what I said, simply trolling is less trouble and more fun.

  • Anonymous
    September 14, 2008
    The comment has been removed

  • Anonymous
    September 14, 2008
    I said the Error Console above, but meant the pop-up JavaScript errors in IE8 and previous Internet Explorer versions. These popup error messages are often next to useless. In Opera the error console pops up and you get a very detailed explanation of the problem.

  • Anonymous
    September 14, 2008
    The recently released Beta 2 of Internet Explorer 8 contains a lot of improvements which are aimed at

  • Anonymous
    September 14, 2008
    .NET Closures Algorithm to Detect Blank Images Performance Analysis Reveals Char[] Array is Better than

  • Anonymous
    September 14, 2008
    I Think the improvements are a great idea,and will be glad to see this happening.

  • Anonymous
    September 15, 2008
    The comment has been removed

  • Anonymous
    September 16, 2008
    @lancenz Those are great feedback.. thanks!  I will make sure it reach the right people.  We will look into the debugger issues also.  If you can send me a specific scenario of the debugger crashing ie8 it would be great.  My id is sameerch AT microsoft DOT com.

  • Anonymous
    September 17, 2008
    In Internet Explorer 8 Beta 2 JScript team has focused on improving developer productivity. You can read

  • Anonymous
    September 17, 2008
    It has been a while since I blogged here (this is an understatement!). Internet Explorer 8 Beta 2 has

  • Anonymous
    September 18, 2008
    As you might be aware that Internet Explorer Beta 2 was released few weeks back. In this JScript team

  • Anonymous
    September 19, 2008
    How can i enable java script at ie8 beta 2? Thanks Regards Haris

  • Anonymous
    September 20, 2008
    Haris, try "options". You can find it there!

  • Anonymous
    September 23, 2008
    The comment has been removed

  • Anonymous
    November 21, 2008
    Recently someone asked me about the best practices for AJAX performance. Though this information is scattered

  • Anonymous
    February 19, 2009
    이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의

  • Anonymous
    March 24, 2009
    During Beta1 and Beta2 pre-releases of IE8, we’ve blogged about the performance optimizations done in

  • Anonymous
    March 25, 2009
    During Beta1 and Beta2 pre-releases of IE8, we’ve blogged about the performance optimizations done in

  • Anonymous
    April 29, 2009
    Originating in Microsoft Research as Ajax View , the Visual Studio 2008 AJAX Profiling Extensions Power