Writing Efficient JavaScript: Chapter 7 - Even Faster Websites

Local variables are, by far, the fastest identifiers both to read from and write to in JavaScript. Because they exist in the activation object of the executing function, identifier resolution involves inspecting a single object in the scope chain. The amount of time necessary to read the value of a variable increases with each step along the scope chain, so the greater the identifier depth, the slower the access is going to be. This effect can be seen in every browser except Google Chrome using v8 and Safari 4+ using the Nitro JavaScript engine, both of which are so fast that the identifier depth has little effect on access speed.

To determine the exact performance impact of identifier depth, I ran an experiment involving 200,000 variable operations. I alternated between reads and writes, accessing the variables from different identifier depths. The page I used for this experiment is located at http://www.nczonline.net/experiments/javascript/performance/identifier-depth/.

Figure 7.2, “Variable read time compared to identifier depth” illustrates the amount of time it takes to write to a variable based on scope chain depth, and Figure 7.3, “Variable write time compared to identifier depth” illustrates the amount of time it takes to read from an identifier based on its scope chain depth (a depth of 1 signifies a local identifier).

Figure 7.2. Variable read time compared to identifier depth

Figure 7.3. Variable write time compared to identifier depth

As these figures clearly indicate, identifiers are accessed significantly faster when they are higher in the scope chain. You can take advantage of this knowledge by using local variables whenever possible. A good rule of thumb is to store any out-of-scope variables in a local variable whenever it’s used more than once within the function. For example:

function createChildFor(elementId){
    var element = document.getElementById(elementId),
        newElement = document.createElement("div");

    element.appendChild(newElement);
}

This function has two references to the global variable document. Since document is being used more than once, it should be stored in a local variable for faster reference, such as here:

function createChildFor(elementId){
    var doc = document,  //store in a local variable
        element = doc.getElementById(elementId),
        newElement = doc.createElement("div");

    element.appendChild(newElement);
}

The rewritten version of the function stores document in a local variable called doc. Since doc exists in the first part of the scope chain, it can be resolved faster than document. Keep in mind that the global variable object is always the last object in the scope chain, and so global identifier resolution is always the most expensive.

The scope chain for a given execution context typically remains unchanged during code execution. There are, however, two statements that temporarily augment the scope chain of an execution context. The first is the with statement, which is designed to allow easy access to object properties by making them appear as local variables. For example:

var person = {
    name: "Nicholas",
    age: 30
};

function displayInfo(){
    var count = 5;
    with(person){
        alert(name + " is " + age);
        alert("Count is " + count);
    }
}

displayInfo();

In this code, the person object is passed into a with block. This allows you to access the name and age properties as though they were locally defined. What actually happens, though, is that a new variable object is pushed to the front of the execution context’s scope chain. This variable object contains all of the properties of the specified object (in this case, person) so that they can be accessed without using dot notation. Figure 7.4, “Scope chain augmentation using the with statement” shows how the scope chain for displayInfo is augmented while the with statement is being executed.

Figure 7.4. Scope chain augmentation using the with statement

Though it seems very convenient when an object’s properties are being used repeatedly, this extra object in the scope chain hurts local identifier resolution. While code within a with statement is being executed, the local function variables now exist in the second object in the scope chain instead of the first, automatically slowing down identifier access. In the previous example, the count variable now takes longer to access because it’s not in the first object of the scope chain. Once the with statement finishes executing, the scope chain is restored to its previous state. Due to this major downside, it’s recommended to avoid using the with statement.

The second statement that augments the scope chain is the catch clause of a try-catch block. The catch clause behaves in a manner similar to the with statement where it adds a variable object to the front of the scope chain while it executes the code in the block. That variable object contains an entry for the named exception object specified by catch. However, the catch clause is executed only when an error occurs during execution of the try clause, making it somewhat less problematic than the with statement, though you should take care not to execute too much code within the catch clause to minimize the performance impact.

Minding scope chain depth is an easy way to get performance improvements with a small amount of work. Avoid unnecessarily augmenting the scope chain and inadvertently slowing down execution.

The classic question of whether to use a switch statement or a series of if and else statements is not unique to JavaScript and has spurred discussions in nearly every programming language that has these constructs. The real issue is not between individual statements, of course, but rather relates to the speed with which each is able to handle a range of conditional statements. The details of this section are based on tests that you can run at http://www.nczonline.net/experiments/javascript/performance/conditional-branching/.

if (value == 0){
    return result0;
} else if (value == 1){
    return result1;
} else if (value == 2){
    return result2;
} else if (value == 3){
    return result3;
} else if (value == 4){
    return result4;
} else if (value == 5){
    return result5;
} else if (value == 6){
    return result6;
} else if (value == 7){
    return result7;
} else if (value == 8){
    return result8;
} else if (value == 9){
    return result9;
} else {
    return result10;
}

if (value == 5){

    return result5;
} else if (value == 9){
    return result9;
} else if (value == 0){
    return result0;
} else if (value == 1){
    return result1;
} else if (value == 2){
    return result2;
} else if (value == 3){
    return result3;
} else if (value == 4){
    return result4;
} else if (value == 6){
    return result6;
} else if (value == 7){
    return result7;
} else if (value == 8){
    return result8;
} else {
    return result10;
}

if (value < 6){

    if (value < 3){
        if (value == 0){
            return result0;
        } else if (value == 1){
            return result1;
        } else {
            return result2;
        }
    } else {
        if (value == 3){
            return result3;
        } else if (value == 4){
            return result4;
        } else {
            return result5;
        }
    }

} else {

    if (value < 8){
        if (value == 6){
            return result6;
        } else {
            return result7;
        }
    } else {
        if (value == 8){
            return result8;
        } else if (value == 9){
            return result9;
        } else {
            return result10;
        }

    }
}

switch(value){
    case 0:
        return result0;
    case 1:
        return result1;
    case 2:
        return result2;
    case 3:
        return result3;
    case 4:
        return result4;
    case 5:
        return result5;
    case 6:
        return result6;
    case 7:
        return result7;
    case 8:
        return result8;
    case 9:
        return result9;
    default:
        return result10;
}

//define the array of results
var results = [result0, result1, result2, result3, result4, result5, result6,
result7,
               result8, result9, result10]

//return the correct result
return results[value];

As mentioned in Chapter 1, Understanding Ajax Performance, loops are a frequent source of performance issues in JavaScript, and the way you write loops drastically changes its execution time. Once again, JavaScript developers don’t get to rely on compiler optimizations that make loops faster regardless of the initial code, so it’s important to understand the various ways to write loops and how they affect performance.

//unoptimized code
var values = [1,2,3,4,5];

//for loop
for (var i=0; i < values.length; i++){
    process(values[i]);
}

//do-while loop
var j=0;
do {
    process(values[j++]);
} while (j < values.length);

//while loop
var k=0;
while (k < values.length){
    process(values[k++]);
}

var values = [1,2,3,4,5];

var length = values.length;

//for loop
for (var i=0; i < length; i++){
    process(values[i]);
}

//do-while loop
var j=0;
do {
    process(values[j++]);
} while (j < length);

//while loop
var k=0;
while (k < length){

    process(values[k++]);
}

var values = [1,2,3,4,5];
var length = values.length;

//for loop

for (var i=length; i--;){
    process(values[i]);
}

//do-while loop
var j=length;
do {
    process(values[--j]);
} while (j);

//while loop
var k=length;
while (k--){
    process(values[k]);
}

for (var prop in object){
    if (object.hasOwnProperty(prop)){  //to filter out prototype properties
        process(object[prop]);
    }
}

//known properties to iterate over
var props = ["name", "age", "title"];

//while loop
var i=props.length;
while (i--){
    process(object[props[i]]);
}

var i=values.length;
while (i--){
    process(values[i]);
}

//unrolled loop
process(values[0]);
process(values[1]);
process(values[2]);
process(values[3]);
process(values[4]);

var iterations = Math.ceil(values.length / 8);
var startAt = values.length % 8;
var i = 0;

do {
    switch(startAt){
        case 0: process(values[i++]);
        case 7: process(values[i++]);
        case 6: process(values[i++]);
        case 5: process(values[i++]);
        case 4: process(values[i++]);
        case 3: process(values[i++]);
        case 2: process(values[i++]);
        case 1: process(values[i++]);
    }
    startAt = 0;
} while (--iterations > 0);

var iterations = Math.floor(values.length / 8);
var leftover = values.length % 8;
var i = 0;

if (leftover > 0){
    do {
        process(values[i++]);
    } while (--leftover > 0);
}

do {
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
    process(values[i++]);
} while (--iterations > 0);

Traditionally, string concatenation has been one of the poorest-performing aspects of JavaScript. Typically, string concatenation is done using the plus operator (+), such as in the following:

var text = "Hello";
text += " "
text += "World!";

Early browsers had no optimization for such operations. Since strings are immutable, that meant creating intermediate strings to contain the concatenation result. This constant creation and destruction of strings behind the scenes led to very poor string concatenation performance.

Having discovered this, developers turned to the JavaScript Array object for help. One of the Array object’s methods is join, which concatenates all items in the array and inserts a given string between the items. Instead of using the plus operator, each string is added to an array and the join method is called when all items have been added. For example:

var buffer = [],
    i = 0;
buffer[i++] = "Hello";
buffer[i++] = " ";
buffer[i++] = "World!";

var text = buffer.join("");

In this code, each string is added into the buffer array. The join method is called after all strings are in the array, returning the concatenated string and storing it in the variable text. Adding the items directly into the appropriate index is slightly faster than calling push for each value. This technique proved to be much faster in early browsers than using the plus operator because no intermediate strings are being created and destroyed. However, browser string optimizations have changed the string concatenation picture.

Firefox was the first browser to optimize string concatenation. Beginning with version 1.0, the array technique is actually slower than using the plus operator in all cases. Other browsers have also optimized string concatenation, so Safari, Opera, Chrome, and Internet Explorer 8 also show better performance using the plus operator. Internet Explorer prior to version 8 didn’t have such an optimization, and so the array technique is always faster than the plus operator.

This doesn’t necessarily mean browser detection should be used whenever string concatenation is necessary. There are two factors to consider when determining the most appropriate way to concatenate strings: the size of the strings being concatenated and the number of concatenations.

All browsers can comfortably complete the task in less than one millisecond using the plus operator when the size of the strings is relatively small (20 characters or less) and the number of concatenations is also relatively small (1,000 concatenations or less). There is no reason to consider anything other than using the plus operator if this is your situation.

As you increase the number of concatenations for small strings, or the size of the strings with a small number of concatenations, the performance gets significantly worse in Internet Explorer through version 7. Also, as the size of the strings increases, the performance difference between using the plus operator and the array technique decreases in Firefox. As the number of concatenations increases, the difference between the two techniques decreases in Safari as well. The only browsers where the plus operator remains consistently and significantly faster with varying string size and concatenation numbers are Chrome and Opera.

With all of the performance variance across browsers, the technique to use is heavily dependent on the use case as well as on the browsers you’re targeting. If your users largely use Internet Explorer 6 or 7, it may be worth using the array technique all the time because that will affect the largest number of people. The performance decrease of the array technique in other browsers is typically much less than the performance increase gained in Internet Explorer, so try to balance your users’ experience based on their browsers rather than trying to target specific situations and browser versions. In most common cases, however, using the plus operator is preferred.

One of the most glaring omissions of JavaScript strings is the lack of a native trim method used to remove leading and trailing whitespace. The most common implementation of a trim function is as follows:

function trim(text){
    return text.replace(/^\s+|\s+$/g, "");
}

This implementation uses a regular expression that matches one or more whitespace characters at the beginning or end of the string. The string’s replace method is used to replace any matches with an empty string. This implementation, however, has a performance issue based in the regular expression.

The performance impact comes from two aspects of the regular expression: the pipe operator, indicating that there are two patterns to match, and the g flag, indicating that the pattern should be applied globally. Taking this into mind, you can rewrite the function to be a bit faster by breaking up the regular expression into two and getting rid of the g flag:

function trim(text){
    return text.replace(/^\s+/, "").replace(/\s+$/, "");

}

Breaking the single replace method into two calls allows each regular expression to become much simpler and, therefore, faster. This method is faster than the original, but you can optimize it even further.

Steven Levithan, after performing research on the fastest way to execute string trimming in JavaScript, arrived at the following function:

function trim(text){
    text = text.replace(/^\s+/, "");
    for (var i = text.length - 1; i >= 0; i--) {
        if (/\S/.test(text.charAt(i))) {
            text = text.substring(0, i + 1);
            break;
        }
    }
    return text;
}

This trim function consistently performs better than other variations. The source of the speed is keeping the regular expressions as simple as possible. The first line removes leading whitespace and then the for loop is used to strip trailing whitespace. The loop uses a very simple, single-character regular expression that matches nonwhitespace characters. This information is used to either remove a character from the string or break the loop. The resulting function performs faster than the previous versions across all browsers. For Levithan’s complete analysis, see his post at http://blog.stevenlevithan.com/archives/faster-trim-javascript.

As with string concatenation, the speed of string trimming matters only if it is performed with enough frequency during execution. The second trim function in this section performs fine for smaller strings over the course of a few calls; the third trim function is significantly faster when used on longer strings.

The single-threaded nature of JavaScript means that only one script can be executed in a window or tab at any given point in time. No user interactions can be processed during this time and so it’s necessary to introduce breaks in long-executing JavaScript code. On simple web pages, the breaks occur naturally as the user interacts with the page. In complex web applications, it’s often necessary to insert the breaks yourself. The easiest way to do this is to use a timer.

Timers are created using the setTimeout function, passing in the function to execute as well as a delay (in milliseconds) before the function should be executed. When the delay has passed, the code to execute is placed into a queue. The JavaScript engine uses this queue to determine what to do next. When a script finishes executing, the JavaScript engine yields to allow other browser tasks to catch up. The web page display is typically updated during this time in relation to changes made via the script. Once the display has been updated, the JavaScript engine checks for more scripts to run on the queue. If another script is waiting, it is executed and the process repeats; if there are no more scripts to execute, the JavaScript engine remains idle until another script appears in the queue.

When you create a timer, you’re actually scheduling some code to be inserted into the JavaScript engine’s queue to be executed later. That insertion happens after the amount of time specified when calling setTimeout. In essence, timers push code execution off into the future, where all long-running script limits are reset. Consider the following code:

window.onload = function(){

    //Page Load

    //create first timer
    setTimeout(function(){

        //Delayed Script 1

        setTimeout(function(){

            //Delayed Script 2

        }, 100);

        //Delayed Script 1, continued

    }, 100);

};

In this example, a script is run when the page loads. That script calls setTimeout to create the first timer. When that timer executes, it calls setTimeout again to create a second timer. The second delayed script cannot start running, however, until the first has finished executing and the browser has updated the display. Figure 7.8, “JavaScript code execution with timers” shows the timeline for this code execution, indicating that no two scripts are run at the same time.

Timers are the de facto standard for splitting up JavaScript code execution in browsers. Whenever a script is taking too long to complete, look to delay parts of the execution until later.

Note that very small timer delays can also cause the browser to become unresponsive. It’s recommended to never use a delay of zero milliseconds, as this isn’t enough time for all browsers to properly update their display. In general, delays between 50 and 100 milliseconds are appropriate and allow browsers enough idle time to perform necessary display updates.

Figure 7.8. JavaScript code execution with timers

Array processing is one of the most frequent causes of long-running scripts. Typically, this is because processing must be done on each member of the array, and so the execution time increases directly in proportion to the number of items in the array. If the array processing doesn’t have to be executed synchronously, it is a good candidate for splitting up using timers.

In my book, Professional JavaScript for Web Developers, Second Edition (Wrox), I describe a simple function that can be used to split up the processing of arrays using timers:

function chunk(array, process, context){
    setTimeout(function(){
        var item = array.shift();
        process.call(context, item);

        if (array.length > 0){
            setTimeout(arguments.callee, 100);
        }
    }, 100);
}

The chunk function accepts three arguments: an array of data to process, a function with which to process each item, and an optional context argument in which the processing function should be executed (by default, all functions passed into setTimeout are run in the global context, so this is equal to window). Processing of the items is done using timers, and so the code execution yields after each item has been processed. The next item to process is always at the front of the array and is removed before being processed. Afterward, a check is made to determine whether there are any further values left to process. If so, a new timer is created and the function is called again via arguments.callee. Note that the chunk function uses the passed-in array as a “to do” list of items to process and so is altered once execution is complete. You can use the function as follows:

var names = ["Nicholas", "Steve", "Doug", "Bill", "Ben", "Dion"],
    todo = names.concat();  //clone the array

chunk(todo, function(item){
    console.log(item);
});

The code in this simple example outputs each name in the names array to the console (available in Firefox with Firebug installed, Internet Explorer 8+, Safari 2+, and all versions of Chrome). The processing function is very short but could easily be replaced with something more complex. The chunk function is best used with long arrays where each item requires significant processing.

Another popular pattern is to perform small, sequential parts of a larger operation using timers. Julien Lecomte presented this pattern in his blog post, “Running CPU Intensive JavaScript Computations in a Web Browser”, in which he showed how sorting of a large data set could be achieved using an inefficient algorithm (bubble sort) without incurring a long-running script issue. The following is an adaptation of Lecomte’s code:

function sort(array, onComplete){

    var pos = 0;

    (function(){

        var j, value;

        for (j=array.length; j > pos; j--){
            if (array[j] < array[j-1]){
                value = data[j];
                data[j] = data[j-1];
                data[j-1] = value;
            }
        }

        pos++;

        if (pos < array.length){
            setTimeout(arguments.callee,10);
        } else {
            onComplete();
        }

    })();

}

The sort function splits up each traversal through the array for sorting, allowing the browser to continue functioning while this processing occurs. The inner anonymous function is called immediately to do the first traversal and then is called subsequently via a timer by passing arguments.callee into setTimeout. When the array is finally sorted, the onComplete function is called to notify the developer that the data is ready to be used. The function can be used as follows:

sort(values, function(){
    alert("Done!");
});

When sorting an array with a large number of items, the difference in browser responsiveness is immediately apparent.