Dave Johnson

JavaScript Benchmarking - Part 3.1

September 15th, 2005

With the open source release of Google�s GOOG-AJAXSLT JavaScript library I thought that it would be interesting to look at the performance in various browsers. It is of particular importance when building responsive AJaX applications on Opera, which does not support XSL-T at this time. Of course there is no reason for using this library in Firefox or Internet Explorer since they both have support for doing XSL-T transformations.

I made a simple XSL-T document that used various functions such as

etc and had it generates some HTML output. I measured the time taken to perform the transform operation with varying numbers of rows in the output HTML. The result is short and sweet and can be seen below.

Luckily, it performs best on Opera which is the browser that does not natively support XSL-T. That being said, in the region of interest here the built-in transformation engines in IE, NS and FF can do the work in the 1ms range.

The question is can there be any optimization done to make the code run faster? Looking through the code I did notice that there are many loops that check values such as

on every iteration and similarly access . Also, there are many functions that use += to concatenate strings and we all know that building an array and calling can be very fast when dealing with large strings. Depending on the size of the transformation there could be performance gains there.

Tests were done on a 2GHz Celeron running Win2K server using IE6, NS8, FF1 and OP8.

Posted in Web2.0, AJAX, XML, XSLT | 1 Comment »

SOAP + WSDL in Mozilla

September 12th, 2005

I sure am behind the times. I just saw found out about the SOAP and WSDL support in Mozilla / Gecko based browsers. This is very cool and I am not sure why more people are not using this � especially in AJaX circles.

The other interesting thing that I found was that you can extend the DOM in Mozilla to support Microsoft HTML Component files or HTC�s - these are used in Internet Explorer to implement things such as SOAP and WSDL support. So you can in fact have SOAP and WSDL support in Gecko with either the built in objects or using HTC�s.

Ok so why aren�t more AJaX people using this built in support for SOAP + WSDL in Mozilla? If you prefer to generate JSON on the server and pass that up you are just crazy since you could instead pass it up as XML embedded in SOAP and then use XSLT on the client to (very quickly) generate HTML or CSS or whatever from the XML.

Posted in AJAX, XML, Service Oriented Architecture, XSLT, Semantic Web | 3 Comments »

Theoretical Dogma

August 24th, 2005

There are a multitude of ways to get data to and from the client in an AJaX application.

A recent article by Jon Tiresn [1] outlines what he feels are the three most useful methods of returning data to AJaX client applications and makes a point of dismissing the idea of sticking to standards and other theoretical dogmas. I highly recommend reading the article but will mention the three methods he discusses which are:

1) simple return
2) snippit return
3) behaviour return

and I will add what I feel is an important fourth:

4) XML return

I added the last one because it is a very important tool in the AJaX toolbox since XML data can be transformed on the client very quickly using XSL-T thus reducing server load, enabling the inherent use of app server data caching and adhering to standard design principles. You can even do various tricks to reduce the size of your XML data so that you are actually transferring very little data.

All of these four options are good if used in the proper situation. I generally agree with Jon that there should not be any of this generic interface (SOAP, SOA, WS-*) type malarky in AJaX applications. There may be some special cases where one might put high value on being able to re-purpose AJaX data and thus make the client and server very loosely coupled but for the most part AJaX services will not be available to the general public and exist primarily to support the user interface.

Furthermore, due to the constraints that JavaScript places on AJaX applications in terms of latency and usability, one has to engineer both the client and sever interfaces for the best performance possible; this often includes performing time consuming operations on the server rather than the client and returning ready to process JavaScript snippets or behaviours as opposed to raw data / XML. This is not interoperable or standards based (yet) but pays huge dividends in terms of application usability.

That being said there may be instances where you are dealing with the same data in both internal and external applications and it might be helpful to be more standards based. Another strong case for being standards based arises from situations where you are building AJaX based components for use by the development community in web applications. These type of developer components should be easily integrated into internal systems and thus can benefit from being standards based - that is why there are standards in the first place after all.

In the end one has to ask several questions to determine what method to use. Some of the important questions to ask about the application would be

• is the data going to be used for several interfaces or systems inside or outside of your company (SOA type situations)
• is the application a one off (Google Suggest)
• how important is application latency
• how important is browser compatibility
• how much traffic and server load is expected
• how much client processing can be done without compromising latency goals
• how important is it to be standards based
• how difficult will it be for a new developer to extend / debug the application
• how much raw data is being transferred between the server and client
• how much formatted (HTML or JavaScript) data is being transferred

and so on (its late and I am tired:)). One thing is certain - the lines that define a traditional MVC architecture can get very blurry when dealing with AJaX.

What are other metrics that people have found useful when considering data access in an AJaX application?

[1] Designs for Remote Calles in AJaX

Posted in Web2.0, AJAX, JavaScript, XML, XSLT | No Comments »

JavaScript Benchmarking - Part 1

July 10th, 2005

As the name suggests this is part I of a series of JavaScript benchmarking blogs. The reason for these is to investigate the performance of various Ajax programming tasks. The first entry investigates how the XSL-T processors of Internet Explorer and Firefox / Mozilla (on Windows 2000) compare and how they compare to pure Javascript code that arrives at the same end result.

So what I have done is loaded some XML and XSL for building a table structure in an HTML page. The transformation is timed and we take an average and standard deviaton for each browser. In Internet Explorer I used the Msxml2.DOMDocument.3.0 object and the XSLTProcessor in Firefox. The XSLT transformation speed is then also compared to a pure Javascript implementation. The Javascript implementation is the fastest method one can use to insert HTML into a web page [1]; a string array is used to store all the rows of the table after which the array join method is called to return a string that is inserted into the DOM using innerHTML, just as the XML/XSL approach does.

The results are somewhat surprising and can be seen below.

(note the y-axis should be in ms not s)

One can see that the XSL-T processor is Firefox / Mozilla leaves much to be desired and is no match for the Javascript method, nor is it any match for either the XSL-T or the Javasctipt method in Internet Explorer. On the other hand, the XSL-T and Javascript methods in Internet Explorer are more or less the same with a slight edge being given to the XSL-T method.

It is curious just how much variance their is on the Firefox XSL-T data. I am not sure what is causing this but all measurements were done 50 times to get the statistics and there was nothing significantly different on the system on which the tests were run.

So for the best cross-browser performance going with pure Javascript is not so bad when presenting large amounts of data to the user. Further tests will look at the performance of XSL-T and Javascript for sorting data, object and class level CSS manipulation and the recently released Google Javascript XSL-T [2] implementation.

These types of JavaScript speed issues are very important for companies like us [3] that make high performance Ajax controls and web based information systems.

[1] Quirksmode
[2] Google AJAXSLT
[3] eBusiness Applications

Posted in Web, AJAX, JavaScript, XML, XSLT | 3 Comments »