JavaScript Performance: Rhino beats IE?

February 5, 2009 at 2:48 am (HtmlUnit, JavaScript, Rhino)

I’ve been examining HtmlUnit’s performance from a couple of different angles lately. As a pure-Java headless browser intended for integration testing, one of HtmlUnit’s big draws is improved performance vis-a-vis native browsers and libraries which drive native browsers (Selenium, WebDriver, etc).

One the one hand, it’s easy to see that HtmlUnit reduces overhead by forgoing a GUI. No layouting, no drawing, no problem. If you poke around a little bit, you’ll also find that HtmlUnit does not download most images (there are some exceptions), nor does it download external CSS files if CSS has been disabled — all advantages in terms of network usage.

However, as you get closer to the RIA end of the web application spectrum, these performance advantages become increasingly overshadowed by JavaScript performance. HtmlUnit relies on Rhino to do the JavaScript heavy lifting behind the scenes, so as web applications become more functional, we’re going to be relying more and more on Rhino’s muscle.

Google just released version 3 of their V8 JavaScript Benchmark Suite, which tests pure JavaScript and pretty much ignores the DOM manipulation side of things — making it a perfect worst-case scenario benchmark with which to compare HtmlUnit to native browsers. In other words, if you use HtmlUnit such that all of its traditional performance advantages are negated (unlikely though that may be), how does it stack up against the native browsers?

Not too bad, as it turns out (bigger numbers are better):

javascript-benchmark1

The good news is that Rhino is more performant than IE 6 or IE 7, so HtmlUnit still beats these browsers in this unrealistic worst-case scenario.

The bad news is that IE is by far the slowest native browser out there in terms of JavaScript execution speed; we can’t assume that it will remain slow forever… can we?

4 Comments

JavaScript Iteration Order

September 10, 2008 at 1:28 am (Chrome, JavaScript, Rhino)

The blogosphere has been flooded with Google Chrome-related posts for the past week or so, especially in the niches catering to web developers, browser developers and JavaScript enthusiasts. I haven’t tried it out yet, but I don’t see why that should keep me from joining the fracas ;-)

The Chrome team’s vision is refreshing. Their technology is intriguing. Their future? Uncertain. However, these topics have been explored in such depth that any effort at original contributions in these areas, at this time, are almost certainly useless.

I did, however, have to smile when I read John Resig’s post on JavaScript in Chrome. In it, he highlights a number of JavaScript issues in this new browser, the third one being for loop ordering:

Currently all major browsers loop over the properties of an object in the order in which they were defined. Chrome does this as well, except for a couple cases… If an object contains a value which is not a primitive… then its properties will be enumerated in a different order from which they were defined.

This is an interesting bug due to one fact: This behavior is explicitly left undefined by the ECMAScript specification… However, specification is quite different from implementation. All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it.

The reason I find this amusing is that the Rhino codebase suffered from the exact same problem, only recently adhering to the de facto standard which in this area subsumes the de jure ECMAScript standard.

We had a number of HtmlUnit users complain about this lapse, and even now the fix is not available in any official Rhino releases — hence HtmlUnit’s Rhino fork.

It appears implementers are doomed to repeat this mistake until such time as this unofficial convention is given official sanction. The recent outbreak of common sense, pragmatism and brotherly love on the ECMAScript committee is cause for optimism.

As John Resig mentions in his post on ECMAScript 3.1, much of the committee’s recent work has focused on standardization of such conventions:

Probably the most important development within all this [ECMAScript Harmony news] is the codification of existing de facto standards. For example, the concept of JavaScript getters and setters (implemented by Mozilla, Apple, and Opera) are going to be quickly fast-tracked into the specification (in the case of getters and setters they already have been). Seeing real-world code quickly make a bee-line for standardization is truly heartwarming. We’ll probably see more of this for topics like ‘let’ and ‘expression closures’ – but which will arrive post-ECMAScript 3.1 (since they require new syntax).

So will definition-order property iteration make it into ECMAScript 3.1? One can only hope, for the sake of the V9, V10 and V11 development teams…

UPDATE: The current (September 1st, 2008) ECMAScript 3.1 spec contains the following comment regarding the text in question:

We considered specifying the enumeration order but there were too many issues with existing implementations that optimize the representation of arrays.

Argh…

1 Comment