JavaScript and Performance Optimization

A few days ago I talked about the different methods that can be used to create a for loop in javascript. I listed the advantages and disadvantages for each approach in terms of readability and performance. That got me thinking - how badly do we need optimization in javascript? On one hand javascript is a perfect model for distributed execution - and on the other hand, javascript is very slow(especially on some browsers).

Advantages of Optimization

The major advantage of optimization is, well, speed. And the most optimized code is regarded by many people as the best code. But in JavaScript, optimization is not just for execution speed. JavaScript code must be optimized for file size as well. This is a speed optimization as well - but in this case it targets download speed rather than execution speed.

Download Speed

Most browsers download the resources specified in the <head> before rendering the content. Since javascript code is included at the head area, the js file must be downloaded before the page can be rendered. So if the javascript code is big, it can slow down the rendering of the whole page.

Execution Speed

JavaScript is notorious for its speed(or lack of it). Many browsers have a very poor implementation of javascript - as a result, javascript have gained the label 'slow language'. This is very visible if you try to use a lot of DOM accessing in your script.

Disadvantages of Optimization

Many books and tutorials extol the benefits of performance optimization. But often they tend to ignore one big disadvantage of optimization - readability. The more you optimize, the more difficult it is to read the code. The other reason is complexity - that is addressed by many people. Due to this reason, many experts discourage blind optimization. Tony Hoare's famous maxim...

Premature optimization is the root of all evil.

Readability is affected by both execution speed and file size optimization.

To reduce file size, the first thing that the authors remove is the comments. I don't have to tell what kind of impact the lack of comments make on the readability of a script. If you are lucky the author stops 'optimizing' after removing the comments. But some overzealous programmers go beyond that - they think whitespaces are a needless waste of bandwidth. <humor>The resulting code resembles cypher text created by the enigma machine in Second World War. I mean, I have seen Perl code that are more readable than 'optimized' javascript codes.</humor>

This effect can also be created by over enthusiastic use of performance optimization too. Have you seen Loop Unrolling? What about Duff's device? With a bit of optimization, you can make you scripts as readable as that. Also, optimization increases the complexity of a program. More complex a program gets - more bugs it will have. And more time is taken to debug it. Keep It Simple, Stup.. um... Silly.

Conclusion

File Size Optimization

Use this only if your javascript file is big - this is true in the case of JavaScript Libraries. But when you choose to do this, maintain 2 files - the original file and the compressed file. Use the compressed file in your site. And use your original file for reading, editing etc. Use a program to convert original code to a compressed format. Make sure that there is a comment at the top of the compressed file with the URL of the original file. Ignore the last line if you are using compression for the purpose of obfuscation.

Performance Optimization

Use common sense to decide when optimization is necessary. If you find a bottleneck, optimize it. But if you don't, don't go around optimizing everything in sight.

Use good and clean code. They are often much faster than ugly code. For example, consider this...

The Right Way

for(var i=0; i<10; i++) {
	var value = document.getElementById("product_"+i).value;

	//	... whatever ...
}

The Wrong Way

for(var i=0; i<10; i++) {
	var value = eval("document.frm.product_"+i+".value");

	//	... whatever ...
}

In this case most javascript programmers will recommend using the first approach. That is because the first method is much cleaner and faster - and is generally considered a better way of writing javascript. Another reason for using the first method is that the second method causes bleeding from the eyes. And, most javascript programmers will kill you if you use eval in any of your scripts. I know I will.

Use optimized code only if there is a visible increase in speed - else discard it for the more readable version.

Optimization is necessary in a system where a lot of computation have to be done using limited resources. But JavaScript coding is nothing like that. In JavaScript, many people from all over the world is executing the same code - the ultimate in distributed execution. But if the script was in the server side, I would try to optimize a bit - as a single system is serving all the visitors. But in client side, the visitors will do the execution.

blog comments powered by Disqus