Showing posts with label Performance. Show all posts
Showing posts with label Performance. Show all posts

Monday, 8 September 2008

Speed Testing Chrome for List Processing

What are we testing?

As Rich Internet Application development progresses, more and more developers are moving towards the functional programming capabilities of JavaScript.

First Order Functions, Closures, Macros and Lists are becoming a mainstream method of development.

When you can tell the computer how to do it, rather that listing what it needs to do, it becomes much easier to write a program and needs a lot less code.

Think recipe instead of precise instructions.

So how does Chrome compare to the other browsers when doing this?

What did we test?

I used JSTR to create a re-usable test of basic Functional programming.

The test creates a list(array) from a DOM collection, runs a filter on the list to identify the required elements, then performs an action on those elements remaining.

Follow this LINK to run the test for yourself.
Paste the link into another browser to test it on different systems.

The test is pretty basic, but it provide a nice demonstration of the capabilites of Chrome.

So how did they do?

Testing 1000 loops on a windows XP machine with 2Gb ram:
Testing used 10 repetitions for averaging.





Conclusions

It looks like the more modern browsers (FF3, Chrome, Safari) are now concentrating a great deal on Javascript performance. A very good piece of news for anyone developing Rich Internet Applications.

I must admit I was surprised by the performance of Safari on WindowsXP but it is nice to get surprises like this.

I had expected Chrome to out perform everything else and was a little disappointed to see otherwise. However, it is definetely a top notch Javascript system and I look forward to watching it develop.

This test does raise the issue that older versions of any browser will have significant differences in run-time speed for your application.

It looks like we will soon be back to the days of specifying a minumim compatible browser version, and the list will be quite short.

Request for Comments

If you have a different operating system or browser... can you please let me know how it performs in this test?
  1. Use the link above to launch JSTR, pre-loaded with the test..
  2. Clear the Console
  3. Press RUN

If you can leave a comment with the output, I will add it to the data collected.

Saturday, 16 August 2008

Performance Testing in JavaScript

Fast pages and quick load times are key factors to keeping visitors on your site.
If you make them wait, they will leave.

So the speed of your JavaScript applications is crucial.

Fortunately, it turns out that JavaScript applications are ripe for performance optimization.

This requires a strong testing framework... enter JSTR.

String Concatenation Performance

A simple example of the type of benefit available from performance testing can come from testing String concatenation.

Javascript allows the use of "+" to concatenate Strings, but it turns out to be rather inefficient if you are building a very big string, eg: dynamically building HTML from AJAX.

Instead, the use of a Array (wrapped to provide a StringBuffer object) provides a huge boost in performance.

[cc lang="javascript" tab_size="2" lines="40"]
function StringBuffer() {
this.buffer = [];
}

StringBuffer.prototype.append = function append(string) {
this.buffer.push(string);
return this;
};

StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
};

var buf = new StringBuffer();
buf.append("this is being added");
alert(buf.toString());
[/cc]

To test this against a normal concatenation:
Copy the String below, and then paste it into the IMPORT function in JSTR.

[cc lang="javascript" tab_size="2" lines="40"] jstr_StringBuffer=KHtuYW1lOiJTdHJpbmdCdWZmZXIiLCBkZXNjOiJUaGlzIHRlc3QgY29tcGFyZXMgdGhlIHNwZWVkIG9mIGJ1aWxkaW5nIGEgbGFyZ2Ugc3RyaW5nIGJ5IGNvbmNhdGVuYXRpbmcgc3RyaW5ncyBvciB1c2luZyBhIFN0cmluZ0J1ZmZlcihhIHdyYXBwZWQgYXJyYXkpLlxuQ29tcGFyZXMgYm90aCBsb25nIGFuZCBzaG9ydCBzdHJpbmcgYnVpbGRpbmcuXG4iLCBsb29wczoiMjAwMCIsIGl0ZXJhdGU6IjUiLCB0ZXN0czpbe25hbWU6InNob3J0U1RSIGNvbmNhdCIsIHNldHVwOiJhU3RyaW5nID0gXCJhZGRpbmcgXCI7XG5iU3RyaW5nID0gXCJTdGFydCBcIjsiLCBjb2RlOiJiU3RyaW5nICs9IGFTdHJpbmc7IiwgaW5jOnRydWV9LCB7bmFtZToibG9uZ1N0ciBjb25jYXQiLCBzZXR1cDoiY1N0cmluZyA9IFwiIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkICBMT05HXCI7XG5kU3RyaW5nID0gXCJTdGFydCBcIjsiLCBjb2RlOiJkU3RyaW5nICs9IGNTdHJpbmc7IiwgaW5jOnRydWV9LCB7bmFtZToic2hvcnRTdHIgU3RyaW5nQnVmZmVyIiwgc2V0dXA6ImVTdHJpbmcgPSBcIiBNb3JlXCI7XG5mU3RyaW5nID0gXCJTdGFydCBcIjtcblxuU3RyaW5nQnVmZmVyID0gZnVuY3Rpb24gKCkgeyBcbiAgIHRoaXMuYnVmZmVyID0gW107IFxuIH0gXG5cbiBTdHJpbmdCdWZmZXIucHJvdG90eXBlLmFwcGVuZCA9IGZ1bmN0aW9uIGFwcGVuZChzdHJpbmcpIHsgXG4gICB0aGlzLmJ1ZmZlci5wdXNoKHN0cmluZyk7IFxuICAgcmV0dXJuIHRoaXM7IFxuIH07IFxuXG4gU3RyaW5nQnVmZmVyLnByb3RvdHlwZS50b1N0cmluZyA9IGZ1bmN0aW9uIHRvU3RyaW5nKCkgeyBcbiAgIHJldHVybiB0aGlzLmJ1ZmZlci5qb2luKFwiXCIpOyBcbiB9OyBcblxuYnVmID0gbmV3IFN0cmluZ0J1ZmZlcigpO1xuYnVmLmFwcGVuZChmU3RyaW5nKTsiLCBjb2RlOiIgYnVmLmFwcGVuZChlU3RyaW5nKTtcblxuIiwgaW5jOnRydWV9LCB7bmFtZToibG9uZ1N0ciBTdHJpbmdCdWZmZXIiLCBzZXR1cDoiXG5oU3RyaW5nID0gXCJTdGFydCBcIjtcblxuYnVmMiA9IG5ldyBTdHJpbmdCdWZmZXIoKTtcbmJ1ZjIuYXBwZW5kKGhTdHJpbmcpOyIsIGNvZGU6ImJ1Zi5hcHBlbmQoY1N0cmluZyk7XG5cbiIsIGluYzp0cnVlfV0sIHZlcnNpb246MX0p [/cc]

Just to give you an idea...
StringBuffer is just faster for short strings
and about 50 times faster for long strings...!

My thanks to Pavel Simakov for this.