Google is a buzzworthy company, though, and I’ve already heard from everyone and their mom about how simple, clean and (most notably), fast the browser is. This piqued my interest. Time for more benchmarks!

I really thought I’d published more benchmark articles by now, but there were only two, so amending them was quick and easy. Here are the results:

Try… Catch Benchmark

This benchmark was setup to see how quickly the standard browsers could execute code that was throwing (and catching) errors. Read the full article here.

As you can see, Chrome is among the highest performers. It executes the plain code insanely fast (never more than 1 millisecond in any of my tests), and is only second to Safari 3 in terms of catching errors quickly.

Conditional Benchmarks

This benchmark is a little more abstract. The objective was to determine which conditional is fastest among if, switch and what I call an object conditional.

Turns out, that was no fluke earlier. Chrome easily blows away the competition here. I might question Google’s motives (and I certainly think it’s a tad shady to have renewed their contract with their now-competitor and then release competing software), but I applaud their speed of my beloved JavaScript.

As most JavaScript programmers know (and many are all-too familiar with), speed is a major factor
when considering how to accomplish any given task.
Once in a while, a script will still run too slowly even after standard optimization tricks have been applied.
When this happens, it makes sense to revisit common practices to see if they can be improved.

I’ve noticed that much of the code that I write contains large if blocks and switch statements. Going back and reading what I’ve written,
I sometimes can’t figure out why I chose one method over the other, given that they can both get the same job done. Usually I think readability is a factor, but which method is
more readable is typically subjective, making that irrelevant.

One use case in which if may be an obvious choice is if the conditionals needed do not translate well into a switch. Here’s an example:

<br /> if (((foo === 1) && (!bar)) || ((foo >= 15) && (bar !== false))) {<br /> // It would be messy to make this a switch statement<br /> }<br />

The above block already lacks a bit in readability, and converting it to switch would be a nightmare.
In this instance, if is the clear choice because of its flexibility. In many cases though, a single variable is being checked in a large set of conditionals.
This is the use case that I wanted to explore.

To me, JavaScript is all about doing things in clever new ways to overcome limitations.
Given that JavaScript is such an expressive, powerful language, is there a different approach that could be taken regarding these conditional blocks?
One method that can be used is what I call an object conditional.
(This concept is not new to the front-end engineering world.)
In the example below I have setup a common, easily readable if block (commented out). After that is the same behavior as described in an object:

<br /> // Get the value from the select box<br /> var bro = document.getElementById(’example-1-select’).value;</p> <p>/*<br /> if (bro == ‘mario’) {<br /> alert(”You selected Mario Mario!!”);<br /> } else if (bro == ‘luigi’) {<br /> alert(”You selected Luigi Mario!”);<br /> } else {<br /> alert(”That’s not a Mario brother”);<br /> }<br /> */</p> <p>var testObject = {<br /> ‘mario’ : function() {<br /> alert(”You selected Mario Mario!”);<br /> },<br /> ‘luigi’ : function() {<br /> alert(”You selected Luigi Mario!”);<br /> }<br /> };</p> <p>if (bro in testObject) {<br /> testObject[bro]();<br /> } else {<br /> alert(”That’s not a Mario brother”);<br /> }<br />

You can run this example by pressing the button below:

Select a Mario brother:

Execute this example

There are many things to consider here.
The first and most obvious being that the object conditional itself uses an if block, making it seem like it would be slower than the if alone right off the bat.
The only other way to emulate both else and default without getting the error testObject[bro] is not a function
is with a try...catch statement.
Since we all know that catching errors is really slow, that’s not an option when we’re going for
high performance. So we’ll have to settle for using an if.

Something else to consider is that the scope is lost when calling a function, a problem that’s not an issue using the other two methods.
This is easily solved, however, by passing whatever you’d like into the function call, for example:

testObject[val].call(args, this, etc);

Now that we’ve got our three different methods, let’s find out which is fastest!

<br /> var benchmark = function(runs, id, func) {</p> <p> var<br /> mStart = new Date().getTime(),<br /> vals = ['a','b','c','d','e'],<br /> len = vals.length;</p> <p> for (var r = 0; r < runs; r++) {<br /> for (var i = 0; i < len; i++) {<br /> func(vals[i]);<br /> }<br /> }</p> <p> var mStop = new Date().getTime(),<br /> elapsed = (mStop – mStart);</p> <p> document.getElementById(id).innerHTML = elapsed + ‘ millisecond’ + ((elapsed == 1) ? ” : ’s’);</p> <p>};</p> <p>function funcA() {};<br /> function funcB() {};<br /> function funcC() {};<br /> function funcD() {};<br /> function funcE() {};</p> <p>var testIf = function(val) {<br /> if (val == ‘a’) {<br /> funcA();<br /> } else if (val == ‘b’) {<br /> funcB();<br /> } else if (val == ‘c’) {<br /> funcC();<br /> } else if (val == ‘d’) {<br /> funcD();<br /> } else {<br /> funcE();<br /> }<br /> };</p> <p>var testSwitch = function(val) {<br /> switch (val) {<br /> case ‘a’ :<br /> funcA();<br /> break;<br /> case ‘b’:<br /> funcB();<br /> break;<br /> case ‘c’:<br /> funcC();<br /> break;<br /> case ‘d’:<br /> funcD();<br /> break;<br /> default :<br /> funcE();<br /> break;<br /> }<br /> };</p> <p>var testObject = {<br /> ‘a’ : funcA,<br /> ‘b’ : funcB,<br /> ‘c’ : funcC,<br /> ‘d’ : funcD<br /> };</p> <p>var testObjectCond = function(val) {<br /> if (val in testObject) {<br /> testObject[val]();<br /> } else {<br /> funcE();<br /> }<br /> };</p> <p>benchmark(10000, ‘benchmark-if-res’, testIf);<br /> benchmark(10000, ‘benchmark-switch-res’, testSwitch);<br /> benchmark(10000, ‘benchmark-object-res’, testObjectCond);<br />

This benchmark sets up three different tests, one with if, one with switch, and one using an object conditional.
Each method checks four different values and then falls into the default, for a total of five states.
This is executed 10,000 times to get a good sampling to work with.
You can execute this benchmark yourself below:

Results will vary of course, but I compiled my findings in the table below.
Using Windows XP, I ran the tests ten times in each of the common browsers and recorded the averages:

It looks like the winner in terms of speed is usually the clever contendor, the object conditional.
But not by a large margin. There’s a lot to be said about code readability, so if
using this method will make your application harder to maintain, it may not be worth it.
Indeed, my colleague Douglas Crockford (Yahoo!’s JavaScript architect) has good cautionary advice here:

In chosing how to structure a program, the first priority has to be clarity of expression. From clarity comes correctness and maintainability. Subordinating clarity to save milliseconds should be discouraged. That is the wrong motivation.

This is certainly true, but sometimes structure unfortunately needs to take a back seat to performance.
The most common use case that comes to my mind is animation.

Say for example, you are implementing an animation that moves an element across the screen and must perform complex calculations over each iteration.
Using an animation library like the one YUI provides, the code might look something like this:

<br /> var anim = new YAHOO.util.Anim(<br /> ‘example’,<br /> {left : {to : 1000}},<br /> 0.1<br /> );</p> <p>anim.onTween.subscribe(function() {<br /> // This function must be as optimal as possible<br /> });</p> <p>anim.animate();<br />

Given this example, optimization is critical, and those few milliseconds gained by using a quicker pattern
could make the difference between a great user experience and a sluggish one.

What are your thoughts? I look forward to your feedback in the comments section.

Edit 9/02/08: Added Google Chrome.

1. A simple, bare-bones variable definition
2. The same code, but with a try...catch block
3. The same code, but with a try...catch block and an intentional error

Here’s the source code:

<br /> var benchmark = function(runs, id, func) {</p> <p> var mStart = new Date().getTime();</p> <p> for (var i = 0; i < runs; i++) {<br /> func();<br /> }</p> <p> var mStop = new Date().getTime(),<br /> elapsed = (mStop – mStart);</p> <p> document.getElementById(id).innerHTML = elapsed + ‘ millisecond’ + ((elapsed == 1) ? ” : ’s’);</p> <p>};</p> <p>var solo = function() {<br /> var giveHim = ‘all the guns’;<br /> };</p> <p>var withTryCatch = function() {<br /> try {<br /> var giveHim = ‘all the guns’;<br /> } catch(e) {}<br /> };</p> <p>var withTryCatchAndError = function() {<br /> var does = {};<br /> try {<br /> does.not.exist = ‘all the guns’;<br /> } catch(e) {}<br /> };</p> <p>benchmark(10000, ‘benchmark-solo’, solo);<br /> benchmark(10000, ‘benchmark-try-catch’, withTryCatch);<br /> benchmark(10000, ‘benchmark-try-catch-error’, withTryCatchAndError);<br />

As you can see, each test is executed 10,000 times to get a good sampling of how long each is taking.
Please note that this script could lock up your browser for a few moments (or even crash it), but you can run this benchmark yourself below:

Using Windows XP, I executed this script ten times using each of the common browsers, taking the averages and compiling them in the table below:

Based on this benchmark, it appears that try...catch adds negligible overhead on its own;
it’s the handling of errors that can add signifant execution time to your scripts.
Internet Explorer and Safari seem to handle errors very quickly, while Opera and especially Firefox could potentially completely ruin a user experience
(such as animation tweening) using this method. Be warned!

Edit 7/11/08: Added Firefox 3.

Edit 9/02/08: Added Google Chrome.