If you have read some preformance tests on JavaScript loops, you may have heard that “while” is faster than “for”. However the question is how faster is “while”? Here are some results, but first let’s take a look on the JavaScript code.

The for experiment

console.time('for');
for (var i = 0; i < 10000000; i++) {
	i / 2;
}
console.timeEnd('for');

The while experiment

console.time('while');
var i = 0;
while (i++ < 10000000) {
	i / 2;
}
console.timeEnd('while');

Note - these tests are performed and measured with Firebug on Firefox.

Results

It's a fact, that you'll get different results as many times as you run this snippet. It depends also on the enviroment and software/hardware specs. That is why I performed them 10 times and then I took the average value. Here are the values of my performance tests. Note that both for and while perform 10,000,000 iterations.

And the Winner Is

While is the winner with an average result of 83.5 milliseconds, while "for" result is 88 average milliseconds.

As the diagram bellow shows, the while loop is slightly faster. However we should be aware that these performance gains are significant for large number of iterations!

This week I’m going to cover one very popular sorting algorithm – the merge sort. It’s very intuitive and simple as it’s described in Wikipedia:

• If the list is of length 0 or 1, then it is already sorted. Otherwise:
• Divide the unsorted list into two sublists of about half the size.
• Sort each sublist recursively by re-applying merge sort.
• Merge the two sublists back into one sorted list.

Here’s the Source

(JavaScript)

var a = [34, 203, 3, 746, 200, 984, 198, 764, 9];

function mergeSort(arr)
{
    if (arr.length < 2)
        return arr;

    var middle = parseInt(arr.length / 2);
    var left   = arr.slice(0, middle);
    var right  = arr.slice(middle, arr.length);

    return merge(mergeSort(left), mergeSort(right));
}

function merge(left, right)
{
    var result = [];

    while (left.length && right.length) {
        if (left[0] <= right[0]) {
            result.push(left.shift());
        } else {
            result.push(right.shift());
        }
    }

    while (left.length)
        result.push(left.shift());

    while (right.length)
        result.push(right.shift());

    return result;
}

console.log(mergeSort(a));

It's interesting to see what happens in the Firebug's console:

[34, 203, 3, 746] [200, 984, 198, 764, 9]

[34, 203] [3, 746]

[34] [203]

[3] [746]

[200, 984] [198, 764, 9]

[200] [984]

[198] [764, 9]

[764] [9]

[3, 9, 34, 198, 200, 203, 746, 764, 984]

Actually the tricky part in this algorithm is the merge function - it does all the work.

You’ve probably seen that you can track the server response headers with Firebug – a wonderful extension to Firefox.

But have you ever asked yourself how to change a response header with Zend Framework.

header()

Typically this is done with the built in PHP function header, where you can setup the header the page must return, but how to make it with Zend Framework?

It’s pretty simple of course, it’s Zend Framework in fact. To be more precise I’ll post a snippet:

$response = $this->getResponse();
$response->setHeader('content-type', 'application/x-javascript; charset=utf-8');
$response->sendResponse();

Perhaps! I was curious how can inefficient selectors impact a page performance. To begin with this topic let me say that inefficient selector is referred usually as nested selector:

div span div {
    border:1px solid red;
}

as you can see here there are three nested tags I use to reference the innermost div. If you’re wondering how you’d know about inefficient selectors – well there is a plugin for the Firebug written by a Google team called Page Speed explaining which of your selectors are inefficient. See the image below.

In the demo page you can find what I was trying to achieve and you can play around with that code to measure by yourself the performance of the different selectors.

So who’s faster? Nested, IDs or Classes?

Actually its pretty though to say. Yet another surprise for me was to notice that the notation:

div.my-class {}

was a bit slower than the marked as “inefficient” by Page Speed:

div span div {}

Another good thing to mention is that there is a difference between div.my-class and .my-class

Question’s answer …

In fact div.my-class is always with a higher priority than .my-class even if you’ve the following code:

div.my-class {
    border:1px solid red;
}

.my-class {
    border:1px solid blue;
}

div span div {
    border:1px solid black;
}

And the computed style for Firefox was …

where “div span div” chain matches the same elements as the previous selectors, as you can see:

so even that div.my-class will be the most important and finally the element will get its red border! It does not depend only on where you put the CSS rules, but also on how they are defined.

After reading one of the latest posts from Stoyan Stefanov’s blog – phpied.com I stumbled upon an interesting construction in JavaScript describing how to check an object property existence. I’m going to cover this case using as an example the console object, which comes with the Firebug enabled, and I think it may be very useful, just because this object is widely used, but doesn’t exists over all the browsers, even under Firefox when Firebug is disabled. This construction is known as the IN statement and it looks something like that:

property in object

which I’m going to cover later in details.

How you detect a variable existence?

There are three main ways to detect the existence of a property I see in my practice.

1. The most widely used:

if ( console ) { ... }

2. The second and more professional one:

if ( typeof console != 'undefined' ) { ... }

3. And finally the third and most unknown:

if ( console in window ) { ... }

Of course two of them are wrong! Which one should be changed?

Is everything working correctly? No!

Lets see how they are working. First of all I’m going to test all of them on Firefox 3.6 either with enabled and disabled Firebug, just shouting with old school’s alert().

Now the first one using the IN statement:

if ( console in window )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

With Firebug disabled the answer is … nothing! No alert! That’s because the syntax is wrong. There’s an error within the IF statement. We should modify a bit the first row like that:

if ( 'console' in window )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

Now everything’s OK. With a disabled Firebug the answer is: “object doesn’t exists!”, and after enabling it, normally the “object exists!”.

Lets move on the next example:

if ( console )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

With Firebug enabled the answer is as we expect: “object exists!”, but after disabling it yet again – nothing?! Why’s that? Because the console object doesn’t exists anymore and the IF statement doesn’t return true or false, but simply crashes. How to modify the code? Simply by adding a window.console instead of console.

if ( window.console )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

Than the answer is: “the object doesn’t exists!” after what we expected!

The third method is the mostly used, just because it’s completely clear what’s the goal of the IF statement:

if ( typeof console != 'undefined' )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

In both disabled and enabled Firebug the answer is as expected!

Now the IN statement may be used if not for the console, but for checking the existence of a property of within an object.

Recently I posted an article about CSS optimization describing five simple steps you can do to speed up the page load time and the bowser execution time. One of the key features is to use effective selectors, but what exactly that means.

Parents and children

In CSS, after the name of cascading, there is a very powerful feature of inheritance and you can simply describe a child style by a selector which can be something like that:

div table tr td a { color: red; }

In reality is very, but very inefficient. Event it is a working example, the browser will find every anchor <a tag within the page than check if it’s child of a td, than tr and so on until the closing outer most div tag.

That’s why the browser is really hard to find every one of these tags just to apply a simple font color. What the big problem is that once you have thousands of tags in that page the browser starts to use CPU and the application starts to be irresponsive.

The solution

Of course there’s a simple solution, which can be described as transformation from inefficient to efficient selectors. Because the browser can find a tag way faster by a given ID or CLASS you can simply convert the code above with something like:

a.my-class { color: red; }

and than change a bit the markup with a tags with that specific class name. Which is a bit tricky, but speedups the performance a lot.

How can I find bad selectors?

Actually that is the big problem. Once you’re into the deep of web development the applications are so big, with so many CSS selectors and so many CSS rules that you simply cannot track that any more.

Hopefully there comes some tools that can describe you everything and point you the inefficient selectors. My personal choice is the Google’s Page Speed plugin, which can be installed to the Firebug on Mozilla Firefox. It can analyze the page and extract a list of inefficient and so called very inefficient selectors that must be fixed!

This post is directly related to the previous post where I explain how to use the Firebug’s console object and in that case its time method. That is really powerful and gives the opportunity to track the performance of a sample JavaScript chunk of code. What it does not do is to give you a more detailed profile of that particular JS code.

That’s because the console’s profile method works on functions and if you’d like to profile a loop it will give you there’s nothing to be profiled. One workaround to that is to use closures.

JavaScript closures

A JavaScript closure is to make an anonymous function and to put the code in it, like so:

(function() {
 for (var i = 100000; i--; ) {
  var a = new Array();
 }
})();

Firebug’s console.profile()

That code can be than wrapped with both console.profile() and console.profileEnd() in something like:

console.profile('my profile');
(function() {
 for ( var i = 100000; i--; ) {
  var a  = new Array();
 }
})();
console.profileEnd('my profile');

That will give a more precise measurement like that one shown on the picture bellow:

As I wrote in my previous post Firebug is giving the ability to test performance of any chunk of JavaScript code with its console.time() method. One of the most discussed topics about performance and one of the most recently examples given in the web is the way to instanciate a new empty array in JavaScript.

new Array() vs. []

Which one is faster? This is the question we’ve seen so many times in the web. I decided to check it with the console.time() method. For my experiment I made 100000 new arrays both way:

var arr = new Array();

and

var arr = [];

Thus the sample code of the first experiment is:

<html>
 <body>
  <script>
   console.time('profile 1');
   for ( var i=0; i < 100000; i++) {
      var arr = new Array();
   }
   console.timeEnd('profile 1');
  </script>
 </body>
</html>

and the results are 12 ms. OK, so far so good. Now I’d like to test the same construction with the other way to make new array instance:

<html>
 <body>
  <script>
   console.time('profile 2');
   for ( var i=0; i < 100000; i++) {
      var arr = [];}
   console.timeEnd('profile 2');
  </script>
 </body>
</html>

And the result is pretty much the same – 11 ms. That’s why I choose to increase the number of iterations of this loop from 100,000 to 10,000,000 and the second chunk of code using the construction arr = [] is finishing its job for around 3400ms or a little bit more than 3 seconds, while the first one is a little bit faster – 2450ms or faster with almost a second.

What if we merge both chunks?

I decided to concatenate the code in something like:

<html>
 <body>
  <script>
  console.time('profile 1');
   for ( var i=0; i < 100000; i++) {
    var arr = new Array();
   }
  console.timeEnd('profile 1');
  console.time('profile 2');
   for ( var i=0; i < 100000; i++) {
    var arr = [];
   }
  console.timeEnd('profile 2');
  </script>
 </body>
</html>

results:

and yet again the same results as if they were separated tests, which of course seems to be pretty natural.

Use console.time()!

That’s the way to get clear example of how fast your code is. Actually this is not a pure sense profile, where you can get minimum and maximum performance times but it gives pretty accurate values.

Although my impression is that most of the web developers use Firefox and most of them are using Firebug, I’m not sure that they use the full potential of this brilliant software.

Firebug’s console view

Firebug is a very powerful tool helping those like me doing his job. But what’s behind the mostly used Firebug’s tools and what’s in the API.

console.log()

For a typical JavaScript programmer the console.log() function is one of his best friends. It can dump useful information in the console tab of the Firebug making everything quite clear. But have you ever asked yourself how to improve your code, how to measure its performance against some constructions.

Performance of JavaScript

I’m sure many of us have read enough articles out in the web about JS performance. Nowadays when the web apps become bigger and bigger, this topic is rising from the bottom of the interesting topics pool. Now everybody’s concerned about it’s app performance and speed.

You’ve probably heart about some basic advices. What to use, what not to use. In a short example I’ll mention only that everybody knows that .appendChild is far slower than the innerHTML. But why is that? How can be sure it’s true.

As I wrote recently you should instantiate your new arrays in javascript with the following construction:

var a = [];

instead of:

var a = new Array();

but as I’ll write here that’s not always true.

console.profile()

One of the useful methods of the Firebug’s console object is the profile() method. It gives you the power to measure timing and performance of any JS function. As described in the Firebug’s web page:

The high-fi approach is to use the JavaScript profiler. Just call console.profile() before the code you want to measure, and then console.profileEnd() afterwards. Firebug will log a detailed report about how much time was spent in every function call in between.

With the simple construction like:

<html>
<body>
<script>
    myFunc = function() {
        var a = [];
    }				

   console.profile();
   myFunc();
   console.profileEnd();
</script>
</body>
</html>

Firebug’s profile output

The simple problem is that thus you cannot just measure some code that’s not a function. This will result in empty profile output in the console’s view:

But hopefully there comes the other method of the console object.

console.time()

It gives anything you’d like to know even if it’s not closed into a function.

Note: remember that both profile and time methods goes with their related profileEnd and timeEnd methods. You’re supposed to enclose the chunk of code you measure with that to be sure that the Firebug’s console will stop the profilers on time.

Now you can simply ask the profiler: what is faster?

The thing I’d like to achieve is something like:

$.log(‘my message’);

when I call it from a pure jQuery code.

function log( msg ) {
   console.log && console.log(msg);
}

That code looks quite correct, but to make all this into a jQuery plugin will need something more.

(function(jquery) {

   var log = function( msg ) {
      console.log && console.log(msg);
   };

   jquery.log = log;

}(jQuery));

After that we can call the $.log function with success and to perform logging of everything we want into the Firebug’s console.

The simple technique used here is a JavaScript closure and simple exportation of the single function log.