Thursday, December 22nd, 2005

JavaScript Performance: Comparing the Atlas and Prototype class idioms

Category: .NET, JavaScript, Prototype

Firstly, it has to be said that micro-benchmarks are the root of all evil.

Now that is out of the way, Jon Meyer took the time to compare styles of subclassing in JavaScript, based on what he sees in Prototype and Atlas.

He analyzes performance implications, giving numbers, and it allows you to see differences between the browsers (well, FF/IE).


In both approaches, there is a penalty for subclassing, especially on IE.

For a performance-critical class, set frequently accessed properties/methods directly on the this instance rather than placing them further up the prototype chain.

The Prototype idiom, generally speaking, produces code that runs marginally slower on IE, when doing general-case method/property access.

The Atlas idiom has the benefit of truly “private” instance variables – you can use closures to define variables that are only visible within a specific method. There appears to be no perf penality for accessing/updating these closure variables.

A major drawback of the Atlas approach is that constructing instances takes much longer. For a class where thousands of instances are constructed (e.g. a IsoDate class), this is a significant issue. For a class that is constructed once and lives the lifetime of the app, this may not be an issue.

The functional iterators of Prototype perform slowly compared to for loops.

Posted by Dion Almaer at 9:56 am
1 Comment

3.2 rating from 20 votes

1 Comment »

Comments feed

This is a frustrating comparison.

It appears to have been run inside a browser and not in the command line interpreters for each engine and so is not well isolated.

I’m also not sure that it covers any of the important debates about writing quick code in a JS interpreter. The amount of time it takes to instantiate a class is a *pittance* compared to the memory cost difference between the tested approaches, and neither seem to actually hit the linearly-increasing object allocation speed issue on IE.

In short, it’s a blind benchmark of the wrong attributes of the wrong idioms. DOM performance, regexp speed, string manipulation, and memory size stats actually matter since they dwarf object instantiation cost. I’m afraid that this set of tests is merely a distraction.


Comment by Alex Russell — December 23, 2005

Leave a comment

You must be logged in to post a comment.