Analyzing JavaScript in Respect to Performance

In a new article Kirk Pepperdine has taken a detailed look at the topic of JavaScript performance. His first observation is that the JavaScript engine specification is much weaker than the JVM's. There are a large number of JavaScript implementations each having different execution profiles. That key point aside he then explores JavaScript in regard to the following topics:

Getters/Setters

...One of the most potentially objectionable bits of advice that I ran across is something I'd not run into for quite some time in the Java world. First the advice, one should avoid using getters and setters in favor of direct access to avoid the overhead of a method call. How is this advice wrong and more importantly how could it be right? Using getters and setters in Java is universally accepted...

Ajaxian and JQuery creator John Resig have discussed getters and setters in the past. However there are performance concerns as this site demonstrates.

Bad Microbench Marks Due to Caching

...Since there is much less dynamic optimization going on in a JavaScript engine one would think that micro-benchmarking would be much easier than it is in Java. Turns out that although the problems are different, microbenchmarking JavaScript isn't so easy either. The most common cause of bad microbenchmarks is caching. The world of web lives and dies with caching. Caching is used everywhere. More over it is often very well hidden...

Memory Leaks

...The most interesting observation was the lack of [good blog entries] on memory leaks and memory profiling ... The big question I had was, just how can one get a memory leak from JavaScript in a browser. Turns out you have a couple of good options. First is to keep a lot of hidden elements in the DOM ... A more interesting and hideous memory leak comes from the use of closures...

CPU Load

...Finally, the small number of blogs about client performance point to an issue that exists, but doesn't seem to hit that many JavaScript applications, namely that any extensive use of JavaScript tends to eat up CPU like anything ... JavaScript can CPU bound the client machine if you try to do too much with it (and in those cases, performance sucks)...

Pepperdine closes by mentioning the new YSlow Firebug based performance tool from Yahoo which checks a number of common JavaScript performance issues as defined by Yahoo. Another recently released tool on the performance front with JavaScript is JsLex which allows jProfile style performance comparisons of JavaScript execution. Microsoft Research is also working on a profiling proxy technolgy called Ajax View.