Analyzing JavaScript in Respect to Performance

Posted by Scott Delap on Aug 29, 2007

Sections

Development

Topics

Javascript ,

Web Frameworks ,

Java

Tags

AJAX

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.

1. Back to top

   Pretty Shallow Article, but a Good Blog Summary

   by Peter Wagener

   The article does a good job of describing the current challenges of developing a large-scale application in JavaScript, but doesn't provide any new or insightful information. Overall it ends up being a summary of various JavaScript blog entries. Nice if you haven't dove into a heavyweight JS app yourself, but not very informative if you're already fighting the good fight against the poorer JavaScript engines out there.
   
   In particular, he is pretty critical of benchmarks that attempt to answer some of the age-old questions, like whether getters & setters really do cause serious performance issues. But unfortunately he doesn't offer any alternative benchmarks either.
   
   Also, the summary of CPU performance is superficial at best. The statement "JavaScript can CPU bound the client machine if you try to do too much with it ..." is laughable; on what platform is that statement not true? One application I worked on was pretty CPU-intensive, and ran abysmally on slow JS engines (read: IE6). But like anything else, spending some time optimizing the code and the data structures provided enough improvements to make performance acceptable.
   
   Still, I'm happy to see that more & more people are looking into the world of JS applications. The alternatives (Flex, et. al) may be attractive short-term, but I think an open solution will eventually win out for web based applications.
   
   The key problem that I see currently is the lack of tools for solving performance and memory leaking issues. FireBug is a god-send in these cases, but still can't hold a candle to the type of tooling we have in the Java world. In our current Dojo-based application we built a memory leak detection framework directly into the application; I'm guessing others are doing similar things. Hopefully in a few years that won't be necessary.

   Reply

• Older >