During a product management meeting last week, I stated that “Performance is a feature, not a Bug.” Not every one got the meaning of that statement, so I will try to explain my thinking behind it.

Read more…

I have create a short synopsis of the jsLex project and how it works.
Injection Engine:

Most of the code that does the injection is based on the Rhino JavaScript Engine. Goto http://www.mozilla.org/rhino/ for more information. After looking into numerous ways to reliably inject the profiling code. I am came to the conclusion writing my own JavaScript parser would have lots of problems and take way to long. So after looking at the dojo compression code, I took the same approach. The code is actually quite simple; the real value comes in the technique of how to put it together. Below is a flow diagraph of how the injection engine works.

At a high level an Ant task loads up the modified Rhino engine, based on the fileset given to the ant task, each of the file in the set are loaded and compiled by Rhino. At this point each file is decompiled with the metrics being injected at the start and end points of each function. The code also keeps track of addition information such as the name of the function and the overall index. After the file is decompiled the Ant task keeps track of the function indexes, names, and files, when the whole fileset has been injected, an addition file is saved that contains a mapping of the function index, with its name.

Index Mapping File:

What is the purpose of this file? Well, in order to consume as little time as possible have the collector can only worry about the index. This file contains the other information only needed during visualization. Slim and trim.
Metrics Collector:

The collector is a JavaScript file that is loaded by the browser before any of the code that is being profiled is called. jsLex.js contains everything need to keep track of counter and timing information. As the code is running, each function will call one of the jsLex tracking functions at the start and end of the function.

jsLex.incProfile(index)
jsLex.enterProfile(index)
jsLex.exitProfile(index)
jsLex.enterFunctionGraph(index)
jsLex.exitFunctionGraph(index)

Each call takes a single parameter that is the unique index of the function in the code base. It is the responsibility of these functions to calculate and accumulate the information. The code itself is not responsible for visualization. This is the responsibility of the last piece of software used to create the project.

Visualization Application:

In order to affect the performance of the running application as little as possible, information collected is not displayed in real-time. The visualization application is responsible for correlating the metric information with the index mapping file. When the user requests the capture of metrics the application retrieve the metrics from the browser running the application. The information is then matched with the information with the profiling file. In additions to the information collected by the Metrics Collector, the visualization app calculates additional information such as; average times, difference counts. There are many screen shots of the visulation engine.
The application itself is built using the Nexaweb Universal Client Framework. I choose this for one, I work there, so promoting the company is a good thing, but more importantly it gave me a lot of functionality out of the box to make it easy to visualize the data.

Wrapping it up:

That’s about it, one, two and three. The source code for the Injection Engine has been made available at http://code.google.com/p/jslex/. Each piece of the project is pretty atomic, so anyone can switch out any piece they want, if a new visualization application is needed anyone should be able to create this application.

To download:

Go to -> http://www.rockstarapps.com/pmwiki/pmwiki.php?n=JsLex.Download

Since June, I have been working on the Apache XAP project (It is coming along nicely we will be packaging it up shortly for a release) as well as the Nexaweb Universal Client Framework that offers both an Ajax and a Java client-side runtime.

The codebases for these frameworks are quite large, not sure of the number of lines, but each has roughly 700 JavaScript files. As with any large-multi-developer codebase, there are times when the performance can be a problem. Different people add code; use functions they don’t understand, just write poorly optimized code or write good code that behaves differently on different browser. No matter what the reason, performance issues in Ajax are one the problems that we (Ajax community) will need to tackle in the upcoming year.

Read more…