Note: This is the YUI 3.x site. Looking for the YUI 2.x site?

YUI 3: The Profiler

The Profiler

The YUI Profiler is a simple, non-visual code profiler for JavaScript. Unlike most code profilers, this one allows you to specify exactly what parts of your application to profile. You can also programmatically retrieve profiling information as the application is running, allowing you to create performance tests YUI Test or other unit testing frameworks.

Getting Started

Include Dependencies

To use the Profiler, include the following source files in your web page with the script tag:

Profiling Functions

The simplest way to use is Profiler is to register a single function for profiling using the registerFunction() method. In order to register a function, it must exist on an object. Since global functions exist on the window object, they can be profiled; functions declared within other functions cannot be profiled unless assigned onto an object. If the function exists globally, then you can just pass in the fully-qualified name of the function:

In this example, there is a global function sayHi() and a global object myObject. These can both be profiled by calling the registerFunction() method. For sayHi(), the first argument is the name of the function and the second argument is the owner object, window. For the myObject.getName() method, the second argument is not necessary because the first argument contains the fully-qualified name of method. Since myObject exists globally, this string can be evaluated to get all of the information that the Profiler needs.

Once a function is registered for profiling, it can be called as usual. The Profiler can then be queried to retrieve information about any of the functions it is profiling. To retrieve information about a particular function, use any of the following methods:

  • getAverage(name) - returns the average amount of time (in milliseconds) that the function takes to complete.
  • getCallCount(name) - returns the number of times that the given function was called.
  • getMax(name) - returns the minimum amount of time (in milliseconds) that the function takes to complete.
  • getMin(name) - returns the maximum amount of time (in milliseconds) that the function takes to complete.
  • getReport(name) - returns an object containing all of the profiling information for the function.

Each of these methods accepts a single argument: the name of the function. This is the fully-qualified name that was used with registerFunction(). For example:

When you are done profiling, you can unregister the functions by using unregisterFunction(), which undoes all of the profiling instrumentation and deletes all profiling data about the given function. Always make sure to retrieve the profiling data for functions before calling unregisterFunction(). To unregister a function, just pass in the same name that was passed into registerFunction(); no other information is necessary.

Profiling Anonymous Functions

Since scripts can consist of methods that aren't accessible via normal means, this represents a distinct challenge to the profiling process. The Profiler doesn't know about any functions that exist in private scopes or that aren't attached to other objects. Even though these can't be profiled automatically, you can use the instrument() method to create a version of any function that contains profiling instrumentation and will be tracked just as any other profiled method. Example:

In this example, the instrument() method is used to create an instrumented version of an anonymous function. This function is given the name "anonymous1" so it can be referenced later. The instrumented function is returned from instrument() and is then called. The report for this function is retrieved using getReport(), just like any other profiled function. While not ideal, the instrument() method is useful if you need finer-grained profiling information.

Profiling Constructors

Profiling constructors is very similar to profiling functions, with the sole exception being the registration of all methods on the prototype for profiling as well. Registering a constructor means that all object instances created via that constructor are being profiled and the results are being aggregated into a single record. For example:

In this example, there is a global constructor MyObject that has two methods on its prototype. By registering the constructor, three entries are made in profiler, one for MyObject, one for MyObject.prototype.getName and one for MyObject.prototype.setName. When the constructor is used to create new object instances, the profiler automatically takes note and aggregates that information. Even though methods are called on individual instances, the data is still collected into one location.

Note: The Profiler cannot profile methods that are defined inside of the constructor. If you create objects that have methods defined in the constructor, it is better to create the instance and then use registerObject() on the instance.

When you are done profiling, you can unregister the constructor by using unregisterConstructor(), which undoes all of the profiling instrumentation and deletes all profiling data about the given constructor and all of its methods. To unregister a constructor, just pass in the same name that was passed into registerConstructor(); no other information is necessary.

Profiling Objects

When an object exists with multiple methods to be profiled, it may be faster to call registerObject(), which registers every method found on the object. This can be especially useful in the case of object literals and inheritance done without using prototypes. The first argument is the name of the object (its name in the profiler) while the second argument is the actual object. Each method is registered as objectName.methodName in the profiler. Example:

In this example, an object obj contains two methods, add() and subtract(). Both methods are registered when obj is passed into the registerObject() method. Information about the methods is then returned via getCallCount() by passing in the complete method names of obj.add and obj.subtract.

When you are done profiling, you can unregister the object by using unregisterObject(), which undoes all of the profiling instrumentation and deletes all profiling data about the given object and all of its methods. To unregister an object, just pass in the same name that was passed into registerObject(); no other information is necessary.

Reporting Results

If you'd like to get the results of all profiling, the getFullReport() method can be called. This method returns an object containing all of the profiling information for every registered function (the data for each function is destroyed when it's unregistered, so this method should be called before unregistering all functions). The getFullReport() method returns an object in the following format:

If you'd like to only return profiling information based on certain criteria, you can pass in an optional filter function to getFullReport(). This filter function receives a single argument, which is the report for an individual function. You can use this data to determine which data to include. The function should return true to include the data and false to ignore it. For example, to get a report for functions that were called at least once, the following can be used:

Using a filter produces an object in the same format as when the filter is not provided; the only difference is the set of functions included in the report.

Stopwatch Functionality

If you want to profile just a specific part of a function, you can do so using the stopwatch functionality that's built into the Profiler. The start() and stop() methods each take a single argument, which is a name that refers to the functionality being profiled. This data is stored in the Profiler along with all other data and can be retrieved using getReport() later on. For example:

This code measures how long it takes to complete a loop that increments a single variable 100,000 times. The name of the Profiler entry is "looptime" and is used in both the start() and stop() methods. Once stop() is called, the data is written into the report and can be retrieved via getReport() in the usual way.

Known Limitations

Since the Profiler works from within JavaScript, there are some limitations:

  • Functions can only be profiled if they're attached to objects.
  • Functions called recursively using arguments.callee will not be profiled correctly. If possible, avoid using arguments.callee in favor of the fully-qualified function name.
  • In order for subclassing using YAHOO.lang.extend() to be profiled correctly, both the superclass constructor and the subclass constructor must be registered with the Profiler prior to the call.

YUI on Mobile: Using Profiler with "A-Grade" Mobile Browsers

About this Section: YUI generally works well with mobile browsers that are based on A-Grade browser foundations. For example, Nokia's N-series phones, including the N95, use a browser based on Webkit — the same foundation shared by Apple's Safari browser, which is found on the iPhone. The fundamental challenges in developing for this emerging class of full, A-Grade-derived browsers on handheld devices are:

  • Screen size: You have a much smaller canvas;
  • Input devices: Mobile devices generally do not have mouse input, and therefore are missing some or all mouse events (like mouseover);
  • Processor power: Mobile devices have slower processors that can more easily be saturated by JavaScript and DOM interactions — and processor usage affects things like battery life in ways that don't have analogues in desktop browsers;
  • Latency: Most mobile devices have a much higher latency on the network than do terrestrially networked PCs; this can make pages with many script, css or other types of external files load much more slowly.

There are other considerations, many of them device/browser specific (for example, current versions of the iPhone's Safari browser do not support Flash). The goal of these sections on YUI User's Guides is to provide you some preliminary insights about how specific components perform on this emerging class of mobile devices. Although we have not done exhaustive testing, and although these browsers are revving quickly and present a moving target, our goal is to provide some early, provisional advice to help you get started as you contemplate how your YUI-based application will render in the mobile world.

More Information:

The YUI Profiler works without any major issues on the Nokia N95 and Apple iPhone default browsers and we'd expect similar behavior on other A-Grade-based mobile browsers.

Support & Community

Forum & Blog

There is a dedicated mailing list for YUI 3. Click the link to visit the list, or use the form below to subscribe:

 

You might also be interested in the general YUI list: ydn-javascript.

In addition, please visit the YUIBlog for updates and articles about the YUI Library written by the library's developers.

Filing Bugs & Feature Requests

The YUI Library's public bug tracking and feature request repositories are located on the YUILibrary.com site. Before filing new feature requests or bug reports, please review our reporting guidelines.

Copyright © 2009 Yahoo! Inc. All rights reserved. Copyright | Privacy Policy | Terms of Use | Job Openings