It’s been awhile since I last Blogged on rockstarapps.com.  In between my last Blog on May 26th and Today, I have been spending much of my time working on building the dojo.E library and traveling around the world (Koren, San Fransisco).  This week is the Ajax Experience Conference, which is one of my favorite conferences and one I have attended three times and talked at twice.  In coordination with the conference were two dojo developer day meetings.

Each day was filled with great information and a lot of cool demos. I was extremely impressed with what I saw. The things people are doing are way more advanced then simple Ajax enhancements. The are truly pushing the Browser, DOM, JavaScript to the edge. I saw fully native and cross browser charting and graphics; get these features right will mean Ajax over the next several years will be able to compete with the plugins (once IE6 is put to pasture).

Below are my take-a-ways from the two days listening to Dojo talks.

Read more…

jsLex Motivation

I started jsLex over a year ago and have been adding features and fixing bugs for all those that asked. The project initially started out as a way to find out what was taking up all the size in my JavaScript files. That’s where the name came from, JavaScript Lexiconical Analyzer or jsLex for short. Even though that feature is still in there and very useful, the project has continued to evolve. Next, I added the JavaScript metricing that makes it possible to find performance bottlenecks with large Ajax application using any web browser.

Now, this version of the project has taken the project to the next level. Over the last year I have talked at many conferences about ways to optimize Ajax applications; reduce the number of requests and reduce the size of the requests. Many others out there have done even more to educate people on ways to do this using a variety of techniques. The issue with using many of the techniques, they are almost always command line driven. I’m a IDE user, so things not integrated into Eclipse are a pain in the ass. 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…