Showing posts with label performance. Show all posts
Showing posts with label performance. Show all posts

Wednesday, June 8, 2011

javascript loop performance

javascript has several types of loops

1. for loop
Probably it is the most usual loop in javascript:
for (var i=0; i<items.length; i++) {
    handle(items[i]);
}

2. while loop
var i=0;
while(i < items.length) {
    handle(items[i]);
    i++;
}

3. do while loop
this loop ensures the loop body gets executed at least once.
var i=0;
do {
   handle(items[i]);
   i++;
} while (i < 10);

The above three loop types are quite common in other language as well. Here is another javascript specific loop:

4.for-in loop
for (var i in items) {
    handle(items[i]);
this loop enumerates the named properties of any object.

Performance:

Only one loop is significantly slower than the others: for-in loop. It is slower due to the fact that each iteration results in a property lookup either on the instance or a prototype. Each time the loop is executed, the 'i' is filled with the name of another property that exists on the object 'items' until all properties have been returned. The returned properties are either on the object instance or inherited through the prototype chain. So, unless you have to iterate over object properties, for-in loop should not be used.

Except for-in loops, other loop types are so close in performance that it doesn't worth trying to determine which is faster. The choice should be based on your requirement instead of performance.

So if loop type doesn't matter in performance, what does? Two issues:
1. Tasks that must be done in loop, the obvious one is the body of the loop: handle(items[i])
2. Number of iterations, very obviously.

When it comes to issue 1, it is not as that simple as it looks. Let's check through loop type 1 in details.

for (var i=0; i<items.length; i++) {handle(items[i]);}

1. The loop first initiate a variable i=0. Fortunately, this task only has to be done once.
2. items.length is a property lookup that has to be done every time in the loop
3. i < items.length is a comparison that has to be done every time
4. (i < items.length) == true is another comparison every time
5. one increment operation i++ every time
6. array lookup every time: items[i]
7. handle(items[i]) every time.

Such a simple loop actually contains a lot of operations. The performance of this loop largely depends on handle(items[i]) function. But, reducing the total number of operations can still help in performance.

1. we don't want to do property lookup, items.length, every time, due to the fact that it is quite unlikely that the length could be changed during the loop. So, we can just do it once:

for (var i=0, length=items.length; i<length; i++){handle(items[i]);}

2. i < items.length, (i < items.length) == true are comparisons every time. We can try to reduce the comparisons by reversing the loop order. Usually, the order in which item is handled is irrelevant to the task. So, we can start the loop from the last item to the first item:

for (var i=items.length; i--;){handle(items[i]);}

In this way, we now simply compare 'i' against zero. Control conditions are compared against the value true, and any nonzero number is treated as true automatically, while zero is equivalent of false. So two comparisons(Is i less than the total items.length? Is that equals to true?) has been reduced to one comparison(Is the value true)

Finally, function based iteration, forEach. It is introduced in 4th editon of ECMA-262. 
items.forEach(function(value, index, itemsArray){handle(value);});

You may already see some implemetations in popular js libraries. One example is Prototype's items.each().

Comparing function based iteration with basic loop types in performance is not that fair, at least that is what i think. Because in some situations function based iteration is very handy and convenient. But if we have to compare, then, as you may already expect, function based iteration is quite slower than basic loop types, due to the overhead that an extra method has to be called every time.

Wednesday, August 5, 2009

refactoring and performance

Many programmers always put performance at the first place in development. However, in my opinion, performance should be the last and least thing we need to worry about. Let's have a look at what Martin Fowler says in his book - Refactoring.

"To make the software easier to understand, you often make changes that will cause the program to run more slowly...but it also makes the software more amenable to performance tuning. The secret to fast software...is to write tunable software first and then to tune it for sufficient speed."

"Changes that improve performance usually make the program harder to work with"

"Build your programm in a well-factored manner without paying attention to performance until you begin a performance optimization stage, usually fairly late in development."

"A well-factored program ... gives you time to spend on performance tunning... Because the code is clearer, you have better understanding of your options and of what kind of tuning will work."

I always believe the first task for developer is to make the software easy to maintain, extend, modify. It also means we should focus more on architecture, structure, design, and coding style.

Unfortunately most of performance-first developers haven't realized that their performance achieved coding creates buggy, hard to understand and maintain system and finally achieves nothing but lost.

Why do we not just use assembly language for programming? We can get better performance than using C++, Java, PHP.

Why do we prefer OOP instead of coding in native language way? Native PHP language code runs faster than OOP code with those classes, objects.

Why do we break code into smaller pieces and functions? Putting everything in one function can save a lot of time than calling other functions and then return to the caller.

Why do we use template engine? Why not just embed PHP into HTML? It is faster.

Why do we use framework? It absolutely runs slower than a index.php.

Why do we use java? Every performance oriented programmer is crying Java is slow.

Monday, March 9, 2009

Performance, easy development, code solid

Performance is an issue often mentioned by developers. Regarding zend framework, one consideration is using Zend autoload or not. Autoload can make our life much easier. As long as we specify the file name and class name in accordance with name space rule, we don't need to put include/require on top of files. Some articles on internet, however, point out that zend autoload slow down the web site's performance. They prefer puting lot of include/require statement on top of files.

For me, i prefer using autoload, because not only it really saves a lot of time, and makes the code look more clean, but also most problems of a web application, based on my opinions, are caused by coding errors, bugs instead of performance.