qooxdoo has build in a cross-browser, pure JavaScript profiler. If the profiler is enabled, each call of a method defined by qooxdoo’s class declaration can be measured. The profiler is able to compute both the total own time and the call count of any method.

Since the profiler is implemented in pure JavaScript, it is totally cross-browser and works on any supported browser.

The profiler can be turned on by the two Makefile variables APPLICATION_PROFILE_SOURCE and APPLICATION_PROFILE_BUILD, which are set to false by default. To enable profiling in the source version and to disable it in the build version just add the following code to the application Makefile:

APPLICATION_PROFILE_SOURCE = true
APPLICATION_PROFILE_BUILD = false

The effect of these variables is that the variant qx.aspects is set to on and the setting qx.enableAspect is set to true. Furthermore, the option –add-require qx.Class:qx.dev.Profile is added to the call of the internal generator script, to ensure that the profiler class qx.dev.Profiler is loaded before qx.Class.

When the profiler is enabled it can be controlled via the profiler API. This can be done either hard-wired in the application code (like the demo browser does for instance) or interactively using a JavaScript shell like FireBug for Firefox or DebugBar for IE.

Profiling a certain action:

• Enable profiling in the Makefile and generate the application
• Open the application in your browser
• At the JavaScript console type qx.dev.Profile.stop() to clear the current profiling data gathered during startup
• Start profiling using qx.dev.Profile.start()
• Perform the action you want to profile
• Stop profiling using qx.dev.Profile.stop()
• Open the profiler output window: qx.dev.Profile.openProfileWindow(50). The parameter specifies how many items to display. The output will be sorted by the total own time of each method. Alternatively you can work with the raw profiling data returned by qx.dev.profile.getProfileData().

In order to interpret the results correctly it is important to know the limitations of this profiling approach. The most significant limitation is due to the fact that the profiler itself is written in JavaScript and runs in the same context as the application:

• The profiler adds some overhead to each function call. The profiler takes this overhead into account in the calculation of the own time but there can still be a small inaccuracy.
• The result of new Date(), which is used for timing, has a granularity of about 10ms on many patforms, so it is hard to measure especially small functions accurately.
• The application is slowed down because profiling is done by wrapping each function. Profiling should always be turned off in production code before deployment.
• Turning on profiling currently breaks most applications in Safari 3.0.2 due to a very limited maximum recursion depth of only 100 (Bugzilla Bug 226). Since the profiler has to wrap each function, the call stack is doubled, which is just too much for Safari.

The output of the profiler can be of great value to find hot spots and time-consuming code. The timing data should be interpreted rather qualitatively than quantitatively, though, due to constraints of this approach.