However, does this really matter for production code?

Blocking before Loading

Virtually all of the examples of AMD code out on the web look something like this:

<script src="some-amd-loader.js"></script>
<script>
someAmdLoader(["moduleA", "moduleB", "domReady!"], function (A, B) {
    var app = new A(), boot = new B(app);
    boot.init();
});
</script>

In this example, we’re loading moduleA and moduleB in parallel. This is the fast way to do it, right? Yes, but also note that we’re loading some-amd-loader.js in a blocking fashion. The second script element (and the rest of the document) has to wait for some-amd-loader.js to finish loading and executing before proceeding.

This isn’t ideal, of course. So how do we fix this?

Answer: by only including one script element in the page and ensuring that that single script allows the page to continue parsing and rendering.

Native async loading

Here’s what we really want:

<script src="myapp-bootstrap.js" defer async="true"></script>

Newer browsers support the async attribute. async="true" instructs the browser that it can proceed to parse and evaluate any future script elements without waiting. You’d think a browser would notice that there’s only one script element, right? Just in case, we’re going to tell it how we want it to behave.

Older browsers don’t support the async attribute. However, they do support the defer attribute. This attribute tells the browser that it may defer execution of the script until a convenient time — even after the body is rendered. Unfortunately, browsers don’t all act the same with this attribute. Most browsers, though, do a fairly good job when there’s only one script element in the document.

Since the browser isn’t waiting for the script’s javascript to load or execute, the script element can be in the head where it belongs. There is no need to put it at the ned of the body element.

So, what’s myapp-bootstrap.js look like in this scenario? The sky’s the limit, but you can imagine a minimal set of requirements:

1. it contains an AMD loader
2. it contains one of the following:
a. instructions to load the rest of the app
b. the actual code for the rest of the app

If you’re compiling/optimizing your AMD modules into a single js file already, it’s not too much harder to concatenate the actual AMD loader onto the front of the file (using requirements 1 and 2b above). Some compilers/optimizers have support for this built in, RequireJS, for example. RequireJS also has a companion loader, almond, that is tiny and can handle the simpler environment inside a compiled file.

So, essentially, all that AMD provided for us in this single-script scenario is a way to ensure ordering of our modules into a single file, it seems. Does this mean that the whole async loading behavior we’ve been touting about AMD is just a bunch of “snake oil“? Not at all. Keep reading:

We ain’t oiling no snakes

Let’s say our web app has several pages. Each of these pages has a core set of modules it requires to function and a set of modules that are unique to it. This is not an unlikely scenario, and is quite likely the most common case.

In this scenario, it could be ideal to allow the common core modules to be fetched from cache and the unique, page-specific modules to be loaded separately. Each subsequent page load would be fast because it’s not loading as much code. For this scenario, requirements 1 and 2a are the best choice. The code inside the single file would look a lot like the original code snippet above:

// loader source code goes here
 
// initialize our app in two parts!
someAmdLoader(["moduleA", "moduleB", "domReady!"], function (A, B) {
    var app = new A(), boot = new B(app);
    boot.init();
});

How finely grained you break up your app is totally unique to your app and your target browsers. If you are targeting older IE’s, then your app is burdened by limited HTTP requests. A small number of fetches per page is best.

More sophisticated apps or ones that can ignore older browsers may be able to take advantage of multiple parallel downloads. However, you must remember that each image, css file, and xhr consumes an HTTP request!

Most of the apps I write have a very sparse body because the UI is built by templates embedded in the javascript. The css is embedded, too (via curl.js‘s css! plugin and the cram optimization tool). This means we can break the app up into several files. Some of these files are loaded when the page loads. Others are loaded when needed (“lazily”).

Do some experimentation to figure out what your ideal situation is. If you already have, please share it with the rest of us in the comments section! There are other ways we could load modules since AMD is very flexible. Do you have an entirely different approach?

Thanks!

– John

[update 2011-09-22 12:35 PM EDT] @getify says that he doesn’t recommend the “defer” attribute due to jQuery/FF3.x issues. see twitter convo here. Also: “defer” isn’t always what you want. Use wisely.

curl stands for Cujo Resource Loader since it’s an integral part of the re-engineering of cujo.js.

An AMD-compatible javascript loader is (surprise, surprise) an asynchronous javascript loader that is savvy about AMD-formatted javascript modules.

[update]
Version 0.3.2 is out! fork it!

What is an asynchronous loader?

Web apps, especially large ones, require many modules and resources. Most of these modules and resources need to be loaded at page load, but some may be loaded later, either in the background or “just in time”. They also need to be loaded as quickly as possible.

The traditional way to load javascript modules is via a <SCRIPT> element in an HTML page. Similarly, CSS files are loaded via a <LINK> element, and text resources are either loaded in the page or via XHR calls.

The problem with <SCRIPT> and <LINK> elements is that a browser must execute them sequentially since it has no idea if one may depend on another. It just assumes the developer has placed them in the correct order and that there are dependencies. (The term “synchronous loading” is used to describe this process since the elements are executed in a single timeline. I think “sequential” is a much better word, but nobody asked me.)

If there are no dependencies between two files, loading them sequentially is a waste of time. These files could be loaded and executed in parallel (i.e at the same time).

An asynchronous loader does just that: it loads javascript files (and other types of files) in parallel as much as possible.

curl.js has lots of company. Other async loaders include LABjs, Steal.js, yepnope.js, $script.js, bdLoad, and RequireJS.

(a more complete list can be found here)

What is AMD?

Asynchronous Module Definition is the CommonJS proposed standard for javascript modules that can be loaded by asynchronous loaders. It defines a simple API that developers can use to write their javascript modules so that they may be loaded by any AMD-compliant loader.

The AMD proposal follows the CommonJS Modules proposal as much as possible. Because of the way browsers load and evaluate scripts, AMD can’t follow it completely without causing significant processing overhead (think serious regex action and eval()). Instead, AMD allows us to place a lightweight wrapper around javascript modules to help work around the shortcomings.

Ultimately, both proposals (AMD and Modules 1.1) are in preparation for an official javascript modules specification and eventual implementation in browsers. (Hopefully!)

If you don’t want to wait for official javascript modules, then don’t. The future is now. AMD works now — and it’s awesome.

AMD’s API focuses on two globally-available functions: require() and define(). require() specifies a list of dependent modules or resources that must be loaded before running a set of code. This code resides in a callback function that is executed asynchronously, i.e. it runs later, not in the current “thread”. Specifically, it executes when all of the dependencies are loaded and ready.

Actually, the proposal says that the require() function could have a different name — or could even be implemented differently. To keep with convention — and to better integrate with non-AMD CommonJS modules — we’re using require(), but curl() is also an alias to require().

It’s more important that the define() method be consistent. This is the method that tells the loader what modules have been loaded by a script. define() also specifies a list of dependencies and a callback function that defines and/or creates the resource when the dependencies are ready. Optionally, define() also takes a name parameter, but this is mainly for build tools and optimizers.

AMD’s API also helps code reuse by providing compatibility with CommonJS server modules. AMD-compliant loaders support the same require() syntax and argument signatures as server-side javascript (ssjs) modules.

Not all async loaders are AMD-compliant. Of the list above, only the following are AMD-compliant:

curl.js http://github.com/unscriptable/curl

RequireJS http://requirejs.org/

bdLoad http://bdframework.org/bdLoad

(there are a few others in that google spreadsheet link)

The beauty of AMD loaders is their ability to remove the drudgery of manually managing dependencies. Since all dependencies are listed within the modules, the loader will ensure that everything is loaded into the browser — and in the right order.

Even better: the modules are always loaded in parallel without blocking the loading process of the rest of the page.

Most of the current AMD loaders also support plugins. Plugins allow you to load CSS, HTML templates, i18n/L10n bundles, CSS generated from LESS, plain vanilla javascript files, etc.  Again, these are loaded without blocking so the performance is optimal.

So how can I get my hands on curl.js?

curl.js is up on github! Fork it or clone it to your local disk and check out the Very Simple Example in the README file.

At the time of this blog post, curl.js is at version 0.3.1 and is not 100% compatible with CommonJS Modules 1.1 (only missing the exports and module parameters). However, I am currently unit-testing 0.3.2, which is 100% compatible!

Compared to other AMD loaders, curl.js is tiny. At 4.5KB (2.1KB gzipped using Google Closure Compiler), it’s half the size of the others. It also employs some wicked cool techniques using promises.

Version 0.3.2 will be ready for production use, despite the zero-dot version number. Please check it out and let me know what you think!

But despite being busy, I felt compelled to post this one. As part of the something really big project, I had to deduplicate a potentially large array of nodes. Dojo doesn’t have a built-in function for deduplication (a.k.a “deduping”). How could it not? Doesn’t everybody have to do this once in a while?

I guess I’ll have to write one. How hard could it be?

It wasn’t because dojo didn’t implement a deduping method that I felt compelled. No, it was the series of events after I wrote my own version. Just after I finished it, one of those smart IDevs at Molecular shared his recent hash map-based implementations that worked only with numbers. Then I noticed that jQuery has a deduping method, unique(). However, it only deduplicates DOM Nodes.

Finally, I ran across this blog post that uses the hash-map method and works only on strings. (Actually, it works on any objects that return unique values from their toString() methods, but that’s not as common as you’d think in Javascript. For example, object literals typically return “[Object object]” from the toString() method.)

It seemed every other implementation used the hash map method and only worked on limited data types. I hate writing the same code twice (unless it’s to improve it), so I decided to write something that works with any data type.

One function to rule them all! (No! Don’t even go there…!)

I probably should have done some research before diving in, but that’s not how I roll. (Where’s the challenge in that?) From previous experience I already knew of at least two ways to do it: a) keeping a hash map of the values (hash map method), or b) pre-sorting the values. The former method (hash map) seemed slower and more memory intensive, so I forged ahead with the second method (pre-sorting).

The pre-sort method works like this:

1. sort the data items in the array
2. loop through the sorted data items:
3. compare each of the data items to the previous one
4. if the previous is the same as the current, don’t add the current item to the output array

Simple enough!

Here’s the code using dojo to wrap the Javascript 1.6 Array iterators:

    function dedup (/* Array */ array, /* Function */ compareFunc, /* Object? */ context, /* Boolean? */ preemptive) {
        //  summary: removes duplicate items from an array. compareFunc should behave
        //      exactly like the lambda function used in array.sort(), returning:
        //       0 - if the two items to compare are equivalent
        //      -1 - if the first item should be sorted to an earlier position than the second
        //       1 - if the first item should be sorted to a later position than the second
        //      Returns an array with no duplicates.
        //      Note: items found later in the array are favored over earlier items. This means
        //      that if am earlier item is found to be a duplicate of an later item, it is not
        //      included in the returned array.  You might ask, "Who cares which one is favored?"
        //      Glad you asked! It depends upon how you define "duplicate". If you wanted to
        //      remove all nodes with duplicate ids, you could supply a compareFunc that inspected
        //      node ids.  The nodes are not identical in this case, just the ids.
        //      If you wish to favor the earlier items, set preemptive = true;
        //      Note: undefined values are omitted from the output array.
        //  array: Array - the array to be deduped
        //  compareFunc: Function - see above
        //  context: Object - context on which to run compareFunc (i.e. the "this" reference from
        //      within compareFunc). defaults to null/window
        //  preemptive: Boolean - set to true to favor earlier occuring items (see above)
        var comparator = function () { return compareFunc.apply(context, arguments); },
            prev,
            keepers = [];
        // by first sorting the array, we know that dups will be adjacent to each other
        dojo.forEach(array.sort(comparator), function (item, pos) {
            if (typeof item != 'undefined') {
                if (typeof prev == 'undefined') {
                    keepers.push(pos);
                }
                else {
                    // is the previous item different from this one?
                    var eq = comparator(prev, item) == 0;
                    if (preemptive) {
                        if (!eq)
                            keepers.push(pos); // add this one
                    }
                    else {
                        if (eq)
                            keepers.pop(); // remove prev one
                        keepers.push(pos); // always add current one (it may be deleted in the next iteration)
                    }
                }
                prev = item;
            }
        });
        return dojo.map(keepers, function (pos) { return array[pos]; });
    }

The dedup() method requires an array (duh) and a comparison function (compareFunc). The comparison function is exactly the same function you’d pass to sort an array. Note that it’s run twice: once to sort the array and once to test if the previous value is the same as the current value.

The context parameter is useful if you need to pull in other data for compareFunc to do its job in the context of some object. For even more control over which duplicate instances are kept, you can use the preemptive parameter. Set this to true to keep items that occur earlier in the array.

I can see some people scratching their heads. Why does it matter which item we keep if they’re duplicates of each other? Well, nobody said they had to be exact duplicates! For instance, maybe you want to reduce a table’s rows to only the ones that have unique integer values in their first cell.

And here’s how you’d do that (error-checking omitted for brevity):

var myDedupedRows = dedup(myTable.rows, function (rowA, rowB) {
    // it's important to use a comparison that works correctly in Array sort() for best efficiency!
    return parseInt(rowA.cells[0].innerHTML) - parseInt(rowB.cells[0].innerHTML);
});

That’s pretty simple if you are already comfortable with writing lambda functions for the sort method, of course.

Deduping numbers:

var uniques = dedup(arrayOfNumberIDs, function (idA, idB) {
    return idA - idB;
});

Deduping object instances:

var uniques = dedup(myObjects, function (objA, objB) {
    // this works for numbers, strings, dates... but don't mix types!
    return objA.keyProperty - objB.keyProperty;
});

Deduping object instances that have multiple key properties:

var uniques = dedup(myObjects, function (objA, objB) {
    var test = objA.keyProperty - objB.keyProperty;
    if (test == 0) // keyProperty is the same, so dig deeper
        return objA.altKey - objB.altKey;
    else
        return test;
});

Deduping numbers the safe way:

var uniques = dedup(arrayOfNumberIDs, function (idA, idB) {
    // force to numbers in case we have strings by accident
    return parseFloat(idA) - parseFloat(idB);
});

At first glance, the pre-sort method looks more complex than the hash map methods, but it’s really not. Once you take out the code that skips undefined values (like all good array iterators should) and the code to allow the preemptive functionality, it’s only a line or two longer.

How about memory usage? Hm. My assumption that my method would use less memory wasn’t as accurate as I thought. In the hash map methods, a temporary array and a hash-map of the non-redundant values are created. In my pre-sort method, a complete copy of the original array and a copy of the deduped array are created. This could go either way, depending on how large the original array is and on how Javascript engines internally manage hash maps (object literals, actually), but it’s likely that the pre-sort has a larger memory footprint. (It’s likely that the Javascript engines create internal data structures to speed-up property look-ups on object literals. However, it’s certain that the engines pre-allocate several kilobytes of space for array items. I’ll bet they allocate a minimum of 16kB per array created.)

Finally, I’m hesitant to claim any performance prizes, either. I assume that since the compareFunc is run at least twice for each item in the array, it’s a performance bottleneck. The hash map methods don’t do much in Javascript besides the loops. The rest is run inside compiled code under the hood of the Javascript engine.

But maybe that’s the price for creating a function that dedups anything?

I’m too lazy busy to test any of my assumptions, but if you are intrigued or bored, please have at it!

And be sure to post any feedback! Did I miss something? Did I make a stoopid mistake? Can you write a version that falls back to the hash map method when using simple data types (and therefore doesn’t need compareFunc)?

What? You don’t use dojo?!?! A jQuery port should be brain-dead simple (s/dojo.forEach/$.each/ and s/dojo.map/$.map/). Here’s a version that replaces the dojo calls with Javascript 1.6 array iterators. (Note: Javascript 1.6 array iterators work in recent browsers only!)

    function dedup (array, compareFunc, context, preemptive) {
        var comparator = function () { return compareFunc.apply(context, arguments); },
            prev,
            keepers = [];
        array.sort(comparator).forEach(function (item, pos) {
            if (typeof item != 'undefined') {
                if (typeof prev == 'undefined') {
                    keepers.push(pos);
                }
                else {
                    var eq = comparator(prev, item) == 0;
                    if (preemptive) {
                        if (!eq)
                            keepers.push(pos);
                    }
                    else {
                        if (eq)
                            keepers.pop();
                        keepers.push(pos);
                    }
                }
                prev = item;
            }
        });
        return keepers.map(function (pos) { return array[pos]; });
    }

Actually, I just wrote that title quickly when I got inspired to start writing. Just before publication, I was going to change it to remove the word “better”. But as an experiment, I decided to keep it to see if it would elicit more feedback. Success!

Two people wanted to investigate cache invalidation, a.k.a. “unmemoization”, some more. Scratch that. Make that three people: I wanted to try it, too.

Here’s my attempt at better unmemoization in Javascript. I’m looking forward to more great feedback! (I really, really need it this time!)

First, let’s simplify the memoize function a bit. In my haste to publish, I missed a good opportunity to increase the performance by using a local variable. I also found a way to shorten it and increase readability by reducing the simplistic if statements into single-line statements using the conditional operator (?:). Here’s the updated version:

function memoize (func, context) {
    function memoizeArg (argPos) {
        var cache = {};
        return function () {
            var arg = arguments[argPos]; // new local variable
            if (argPos == 0) {
                return arg in cache ? cache[arg] : cache[arg] = func.apply(context, arguments);
            }
            else {
                return arg in cache ? cache[arg].apply(this, arguments) : cache[arg] = memoizeArg(argPos - 1);
            }
        }
    }
    return memoizeArg(func.length - 1);
}

This looks better to my eyes — although the cache assignments are somewhat hidden in the last operand of the conditional operator. (Doh! Bad programmer, bad!) Oh, and look! I succumbed to the func.length precedence over func.arity as noted by igstan on Ajaxian.

Scheduled whole-cache reset

If you looked at any of the unmemoize features in the links from the previous post or at Dave’s code snippet in the comments, you’ll see that there are [at least] two ways to reset the cache: at an explicit time (scheduled), and just-in-time (JIT). Scheduled reset uses the setTimeout function and JIT uses date math.

Here’s an example of scheduled reset. It resets the entire cache after a given delay after its first use.

// whole-cache reset via setTimeout
function memoize2 (func, context, /* msec */ cacheLifetime) {
    function memoizeArg (argPos) {
        var cache = {};
        // reset the cache after the specified timeout:
        setTimeout(function () { cache = {}; }, cacheLifetime);
        return function () {
            var arg = arguments[argPos];
            if (argPos == 0) {
                return arg in cache ? cache[arg] : cache[arg] = func.apply(context, arguments);
            }
            else {
                return arg in cache ? cache[arg].apply(this, arguments) : cache[arg] = memoizeArg(argPos - 1);
            }
        }
    }
    return memoizeArg(func.length - 1);
}

Wow. This is really ill-conceived. The first cache to be created (let’s call it the root cache) is the first one destroyed. Since all other caches (for the other parameters) are reachable hierarchically through the root cache, they’re unreachable as soon as the root cache is destroyed. Therefore, we’ll potentially have several unreachable caches wasting memory until their setTimeouts execute (which could be as much as cacheTimeout msec later).

If it’s not immediately apparent to you why this is true (and it wasn’t for me), then note that there are now two function closures with a reference to the local cache variable: 1) the returned function, and 2) the anonymous function in the setTimeout (a.k.a. “setTimeout function”). When a higher-level cache is reset/released via its “setTimeout function”, the references to the lower-level caches (via the returned functions from the calls to memoizeArg()) are released. However, the references to the lower-level caches from their corresponding “setTimeout functions” are not released until those setTimeouts execute!

Strike one!

(If you’re not experienced in functional programming, this is probably very confusing. Either that, or my explanations need a lot more work.)

Scheduled reset of individual cache entries

OK. What about if we invalidate individual cache items instead of whole caches? Would that fix the situation? Lets see:

// cache entry reset via setTimeout (each entry times out individually)
function memoize3 (func, context, /* msec */ cacheLifetime) {
    function memoizeArg (argPos) {
        var cache = {};
        return function () {
            var arg = arguments[argPos];
            // schedule this cache entry for deletion if it's our first time
            if (!(arg in cache))
                setTimeout(function () { delete cache[arg]; }, cacheLifetime);
            if (argPos == 0) {
                return arg in cache ? cache[arg] : cache[arg] = func.apply(context, arguments);
            }
            else {
                return arg in cache ? cache[arg].apply(this, arguments) : cache[arg] = memoizeArg(argPos - 1);
            }
        }
    }
    return memoizeArg(func.length - 1);
}

There! Fixed! Um…right?

Not really. We’ve got the same exact problem: all of the anonymous functions in the setTimeouts (again, “setTimeout functions”) are holding references to our caches! Even though our cache entries will get cleaned up one entry at a time sooner, they’ll still be wasting memory for a while.

Furthermore, there will be hundreds or thousands of active setTimeouts when there are a hunreds or thousands of values to cache. I haven’t done any formal testing, but I’ll wager that this creates a bad situation in some browsers / environments. (Yes, I’m looking at you, IE 6!)

Strike Two!

Reset the cranium

This is really bothering me. It’s the recursion and closures that are causing the problem! And those are the very things I set out to utilize to make a “better” memoizer!

It’s time to reset my cranium rather than strike out. Lots of ideas are coming in to my head, but none of them feel right. None of them deserve the word, “better”. Not to me, anyways.

If you have some suggestions, please let me know!

JSConf 2009

Track A presentations from JSConf 2009

One of the Track A speakers was Stoyan Stefanov, a really smart guy from Yahoo. His presentation was about high-performance web apps, but on one slide in particular, I was struck by his implementation of memoization (slide 79 of 87) because he used the function instance to cache the results of the function itself.

If you’re not familiar with memoization, here’s a great overview:

In computing, memoization is an optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously-processed inputs.

Memoization (Wikipeida)

In other words, it’s a way to cache the results of function calls so that repeated expensive computations or lengthy lookups can be avoided.

Here’s Stoyan’s example:

function myFunc(param){
    if (!myFunc.cache) {
        myFunc.cache = {};
    }
    if (!myFunc.cache[param]) {
        var result = {}; // ...
        myFunc.cache[param] = result;
    }
    return myFunc.cache[param];
}

(Use your imagination to fill in some complex or lengthy task in place of the line with the “…”!)

Again, what struck me was his use of the function instance to cache the results. In Javascript, functions are first-class objects and can be assigned properties just like any other object. But should we do this? It certainly seems like this could cause intractable problems if used widely. Imagine if everybody started decorating functions and methods with properties? (Actually, debuggers such as Drosera and Firebug now use properties on function instances to help identify them in logs and traces. It seems to me we should try not to invade on that space!)

So, of course, I set out to answer the question, “Do we really need to use the function instance to hold the result cache?”

The answer is “No”. It’s really quite easy to avoid, too.

Keep reading if you’re interested in the steps I took to come to a general purpose solution. Otherwise, click here to go straight to it.

A simple example

Here’s the simplest form: a constant-valued function with one parameter.

// constant-valued function. not very interesting
var memoizedFunc0 = (function () {
        var result;
        return function () {
            // in a real-world example this next line would do some
            // complex math instead of just returning a date object
            return result || (result = new Date());
        }
    })();

Notice that we use an auto-execute, anonymous function (the outer function) solely to create a closure around the result variable. Also notice that the variable, memoizedFunc0, is assigned a reference to the inner anonymous function because the outer function executes immediately and returns it. The inner function is the one that gets executed when memoizedFunc0 is called later in our program.

The memoization happens in the inner function’s return statement. We’re using the short-circuit Boolean OR operator (||) to return result if it is assigned. Of course, during the first execution, the second half of the statement runs ((result = new Date())), assigning a value to result.

Admittedly, this is a very boring example. Stoyan’s was much more interesting since the memoized function took a parameter and returned a different result for each possible parameter. So let’s take a look at a multi-valued memoized function:

// multi-valued function with string-serializable param
var memoizedFunc1 = (function () {
    var cache = {};
        return function (param1) {
            return param1 in cache ? cache[param1] : (cache[param1] = new Date(param1));
        }
    })();

This is similar, but we use a native Javascript object to cache function results. As long as the parameter, param1, is primitive* (or is serializable to a unique string), this will work great. Property names must be serialized to strings. Objects that do not have a toString() method to generate a unique string will generally not work. In most situations, though, you’ll have an id or key that you can use, anyway.

The inner function simply checks if it already has a value cached and returns it. Otherwise, it generates a value, caches it, and returns it.

Success! A memoized function that does not pollute the function instance (and doesn’t use global variables like some other implementations I’ve seen).

A more interesting case: two parameters

But let’s not stop there. What if we have two parameters? I guess we could generate some sort of string key out of the parameters and use the single-parameter memoized function. But why? Generating a unique hash code is expensive and bulky. Let’s try to build a 2-parameter memoized function without that.

// multi-valued function with two params
// this time we use two levels of closures and two cache objects
var memoizedFunc2 = (function () {
    var cache1 = {};
        return function (param1, param2) {
            if (!(param1 in cache1)) {
                cache1[param1] = (function () {
                    var cache2 = {};
                    return function (param2) {
                        return param2 in cache2 ? cache2[param2] : (cache2[param2] = new Date(param1, param2));
                    }
                })();
        }
            return cache1[param1](param2);
        }
    })();

Heh. The solution is to build two levels of closures! The first level creates and caches the second level as needed! The first-level cache ends up holding a reference to an inner anonymous function for each unique param2 (and each inner function has it’s own unique closure).

A general purpose “memoizer”

The two-parameter case is quite ugly and unwieldy, in my opinion. However, it shed some light on a general-purpose solution, a “memoizer” I’d like to call it. With a little bit of work, I was able to devise a memoizer for any function with explicitly-declared parameters. Here it is:

// memoize: a general-purpose function to enable a function to use memoization
//   func: the function to be memoized
//   context: the context for the memoized function to execute within
//   Note: the function must use explicit, primitive parameters (or objects
//     that generate unique strings in a toString() method)
function memoize (func, context) {
    function memoizeArg (argPos) {
        var cache = {};
        return function () {
            if (argPos == 0) {
                if (!(arguments[argPos] in cache)) {
                    cache[arguments[argPos]] = func.apply(context, arguments);
                }
                return cache[arguments[argPos]];
            }
            else {
                if (!(arguments[argPos] in cache)) {
                    cache[arguments[argPos]] = memoizeArg(argPos - 1);
                }
                return cache[arguments[argPos]].apply(this, arguments);
            }
        }
    }
    // JScript doesn't grok the arity property, but uses length instead
    var arity = func.arity || func.length;
    return memoizeArg(arity - 1);
}

This still might look a little crazy, but it’s really quite simple. To satisfy an infinite number of parameters, we simply use recursion. Every time we recurse, we create another closure. This just happens in Javascript. It’s a natural side-effect of recursion in the language. All we have to do is use the closures to cache our results.

Our memoize function takes two arguments. The first is a reference to the function we want to memoize. The second is the context the memoized function should run in. For instance, if we want to memoize an object method, we would pass the method in as the first parameter and the object itself as the second parameter.

When the memoize function executes, it first discerns how many formal (explicit) parameters the function has. Javascript uses the arity property for this purpose. Of course, no interesting Javascript project would be complete without a Microsoft caveat of some sort. For some idiotic reason, JScript uses the length property instead of arity. Other Javascript engines followed suit and deprecated the arity property in favor of the length property.

Next, memoize calls its inner function memoizer on the last parameter. memoizer constructs a local cache and returns an inner function that either executes and caches our original function if we’re at the first parameter — or else it caches and executes a call to memoizer with the previous parameter (argPos - 1). Each time the function, memoizer, is recursively called it creates a closure around its own cache variable.

Notice that we’re using the apply method when we finally call our original function. This allows us to bind to our original context. We’re also using apply when we recursively call memoizer. This allows us to pass the arguments through without knowing how many arguments there are. The this passed into these calls is arbitrary and could easily have been anything else, including null.

I don’t know why I chose to start at the last parameter and go backwards. This routine could go in either direction. I also have no idea whether this memoizer is any faster or leaner than Stoyan’s. I imagine it doesn’t matter when you consider that both should be much, much faster than the lengthy XHR call or computationally intensive calculation they are meant to prevent.

OK. Cool. But … um … why?

Yes, memoization is a neat concept. But why use it rather than just hand-coded caching mechanisms? It’s easy enough to write a caching routine, right? Here are a few good reasons:

• hand-coded caching mechanisms obfuscate your code
• multi-variate caching routines are bulky in Javascript
• fewer lines of code means fewer bugs
• Java programmers will think more highly of you*

*Javascript kicks a$$. Show those stodgy back-end guys what we’re capable of!

Let’s try it out

So, let’s test it. First, let’s create a sample object to work with. This object has an “expensive” method that uses an XHR request to fetch server-side resources.

// myObj constructor
function myObj () { };
 
myObj.prototype = {
 
    expensiveAjaxLookup: function (y, mo, d, h, mn, s) {
        // OK.  No XHR.  Just pretend it does something on the server!
        // Instead we're just going to construct a date string.  Lame, I know.
        return this.prop + new Date(y || 0, mo || 0, d || 0, h || 0, mn || 0, s || 0);
    },
 
    // a public property to prove that "this" is really "this" in our memoized methods
    prop: 'my date: '
 
}

In order to prove that our memoized methods didn’t mangle the context of the original method, I added a public property and used it in the expensiveAjaxLookup method. If our memoized methods lost their context, then this property would be undefined.

Tests:

var o = new myObj();
o.memoizedLookup = memoize(o.expensiveAjaxLookup, o);
// Note: 8 == September, not August in Javascript
console.log(o.memoizedLookup(2009, 8, 17));
console.log(o.memoizedLookup(2009, 8, 16));
console.log(o.memoizedLookup(2009, 9, 16));
console.log(o.memoizedLookup(2009, 8, 16));
console.log(o.memoizedLookup(2009, 8, 21, 13, 26, 17));
console.log(o.memoizedLookup(2009, 8, 21, 13, 26, 17));

Output:

my date: Thu Sep 17 2009 00:00:00 GMT-0400 (EDT)
my date: Wed Sep 16 2009 00:00:00 GMT-0400 (EDT)
my date: Fri Oct 16 2009 00:00:00 GMT-0400 (EDT)
***** cache hit!
my date: Wed Sep 16 2009 00:00:00 GMT-0400 (EDT)
my date: Mon Sep 21 2009 13:26:17 GMT-0400 (EDT)
***** cache hit!
my date: Mon Sep 21 2009 13:26:17 GMT-0400 (EDT)

As you can see, the context was correctly bound. Otherwise, we’d see ” undefinedThu Sep 17 2009 00:00:00 GMT-0400 (EDT)“. The lines that say “***** cache hit!” are some debugging statements I threw in. I sprinkled some console.log() calls all over the memoize function to ensure that the caches were being used as expected. They are, of course. I’ll leave it as an exercise for you to study the behavior of the function, if you are so inclined. I found the output very interesting and revealing. Go ahead. Have fun with it!

So, what uses can you conceive for memoization in web apps? Is it only good for caching XHR requests or summing Fibonacci series? Please leave a comment or let me know on Twitter!

It’s certainly possible to add both features without either of those sacrifices. I have some ideas how it could be done. Do you have an implementation that works? If so, please leave a comment!

Memoization in JavaScript

Timed Memoization

In this article, memoization is used to speed up Bezier curve calculations: One-Line JavaScript Memoization

I also updated the text to clarify that the arity property has been deprecated in favor of the length property.

Your fastest Javascript projects are the ones that have the least Javascript!

Sure, Javascript engines have matured. Safari’s Nitro, Chrome’s V8, Firefox’s TraceMonkey, and Opera’s Carackan all kick some serious butt. (IE8′s JScript, unfortunately, still sucks wind.) However, routines written in C++ still run orders of magnitude faster in most cases.

Don’t write Javascript to do something your browser already does at compiled-code speeds.

Do you have any idea now many person-years of effort went into the regular expressions engine in your browser? Tap into that resource!

Here are some other resources you may be under-utilizing:

• Array.prototype.join (example)
• Array.prototype.slice (example)
• RegExp (many string-related optimizations!)
• Array iterators
• DOM selectors (such as Acme (dojo) and Sizzle)

I’ll dive into each of these in later blog posts, but here’s a teaser. This example shows how to replace a relatively slow while loop with an Array iterator.

Our while loop:

var nodes = dojo.query('*[title]'), // using dojo just as an example
    found, // we're looking for a particular node and will store it here
    len = nodes.length, // performance boost to grab this outside of the loop
    i = 0; // just an iteration counter
 
while (!found && i < len) {
    // found will remain false until we find our node
    found = nodes[i].getAttribute('title').indexOf('Loading') >= 0 && nodes[i];
    i++;
}
if (found) {
    // do something with <<found>> here
}

That’s not a bad while loop. You’ll notice that I am overloading the meaning of the found variable. This is an acceptable practice in high-performance situations as long as the code is well-documented to prevent confusion.

Here’s the same loop utilizing the Array iterator some wrapped by dojo NodeList’s some method:

var found; // we're looking for a particular node and will store it here
dojo.query('*[title]').some(function (node) {
    // found will remain false until we find our node
    found = node.getAttribute('title').indexOf('Loading') >= 0 && node;
    return found;
});
if (found) {
    // do something with <<found>> here
}

Leaner! Faster! Sexier!

OK. Here’s the point where I scratch my head. I just ran both of these against dojocampus.org in FF 3.1 and Safari 4.0. To my surprise, the while loop performed slightly better than the some (1ms difference). I removed the [title] attribute from the query selector to get some better test data. Same story.

There was a big difference in IE7, though.

I guess the latest Javascript engines really do kick butt!!!!

My best guess is that the NodeList that dojo.query returns is slowing our example code. A NodeList is not a true array. It is an Array-like object, which simply means it exposes its list of items as properties whose names are Cardinal number and also exposes a length property. So I created a quick and dirty test on a true array:

// using some
var a = [];
for(var i = 0; i < 100000; i++) { a[i] = new Date(2009, 1, i); };
var found, s = new Date();
a.some(function (item, i) {
    found = i == 99999 ? item : false;
    return found;
});
console.log((new Date()) - s, found);
 
// using while
var len = a.length, found = false, s = new Date(), i = 0;
while (!found && i < len) {
   found = i == 99999 ? a[i] : false;
    i++;
}
console.log((new Date()) - s, found);

The results showed that some ran about 17% faster in Firefox 3.0, 32% faster in Firefox 3.1beta, and 43% faster in Safari 4.0beta. Of course, the code inside our loop is very simple. More complex code will consume a larger slice of the total time and will therefore make the effect of the loop mechanism less important.

Moral of the story: to get the best performance when looping through real arrays (rather than Nodelists or Array-like objects), use the Array iterators or their browser-safe counterparts in the major libraries. When using NodeLists, either method works great as long as you’ve tuned your loop correctly. (Sounds like another blog post…)

I’d like to hear from you! What library do you use and how does it handle Array iterators?

var StringBuilder = function (str) {
    var _stack = str ? [str] : []; // str == initial string to start, if any
 
    // append can take one or more strings as arguments
    this.append = function () {
        _stack.push.apply(_stack, arguments);
        return this;
    }
 
    this.toString = function (separator) {
        return _stack.join(separator || '');
    }
}

Unlke Java’s implementation, we’ve added a separator parameter to the toString() method. This would be very helpful in creating HTML or CSV using our object.

I was thinking it would be fun to add a few more features of Java’s StringBuilder onto our decidedly simple example. Here’s how we could add a separator property and a length property (with setter and getter):

var StringBuilder = function (str) {
    var _stack = str ? [str] : [], // str == initial string to start, if any
        _length = str.length; // length of initial string
 
        this.separator = ''; // separator used when concatenating strings in the stack
 
    // public methods 
 
    this.append = function () {
        // append can take one or more strings as arguments
        _stack.push.apply(_stack, arguments);
        toArray(arguments).forEach(function (str) { _length += str.length });
        return this;
    }
 
    this.getLength = function () {
        return _length;
    }
 
    this.setLength = function (len) {
        // coalesce what we've already got and cut it to length
        // Note: this does not expand the string. it only clips it.
        _stack = [_coalesce(this.separator).substr(0, len)];
        _length = len;
        return this;
    }
 
    this.toString = function (altSeparator) {
        return _coalesce(altSeparator == undefined ? this.separator : altSeparator);
    }
 
    // private methods
 
    function _coalesce (separator) {
        // consolidates all of the string entries into one string
        var str = _stack.join(separator || '');
        _stack = [str];
        _length = str.length;
        return str;
    }
}

See my previous post for the implementation of toArray. Unfortunately, IE 6 & 7 are pitifully behind the rest of the Javascript world and need additional help. See the following article from Mozilla for implementing the forEach iterator method in IE:

forEach

toArray

There’s a potentially nasty side-effect in the setLength() method. If you were planning to use the altSeparator parameter in the toString() method, but you use the setLngth() method first, the separator property will be used instead! Either we should create excellent documentation; write a somewhat slower, but safe implementation of setLength(); or remove the altSeparator parameter (and possibly the separator property) and move it to the constructor.

Sample output:

var sb = new StringBuilder('fun');
sb.append('stuff', 'with', 'javascript');
sb.separator = ' ';
sb.setLength(10);
'string="' + sb.toString() + '" length=' + sb.getLength();
 
"string="fun stuff " length=10"

var StringBuilder = function (str) {
    var _stack = str ? [str] : []; // str == initial string to start, if any
 
    // append can take one or more strings as arguments
    this.append = function () {
        _stack.push.apply(_stack, arguments);
        return this;
    }
 
    this.toString = function (separator) {
        return _stack.join(separator || '');
    }
}

This routine runs up to 8x faster in IE6 than normal string concatenation using the + and += operators! In IE7, I’ve clocked a 4x improvement.

Firefox 3.0 gets about a 20% speed boost. Safari 4 and Chrome get less than a 10% speed boost.

It would be an easy exercise to modify the StringBuilder class’ append method and constructor to take an existing StringBuilder object instead of a string.

Similary, DOM properties, such as Element.childNodes, return a NodeList, which is also array-like.

If you’ve ever been frustrated that you can’t use array methods on these array-like collections, then the following function is your new friend:

function toArray (obj) { 
    return [].slice.call(obj, 0); 
}

I like this version because it’s so compact! It’s also very fast since it runs at compiled-code speeds. Here’s a version that even faster because it eliminates the construction of the stub array ([]) each time:

(function (ns) {
    var _a = [];
    ns.toArray = function (obj) { 
        return _a.slice.call(obj, 0); 
    }
})(window);

I used a closure to hide the stub array and keep the global namespace clean. Pass-in your own object / namespace (instead of window) to use the toArray function as a method on that object.

Most Javascript libraries have this feature built-in already, but this first example is one of my all-time favorites since it’s so short!

[Update: kangax improved my toArray function greatly (see discussion). Here are the results:]

var toArray = (function (slice) {
    return function toArray (object) {
        return slice.call(object, 0);
    }
})(Array.prototype.slice);

I remember the first time I saw something like this. It made my head ache. It’s best to go line by line, starting at the middle:

return slice.call(object, 0);

If you’ve understood the post this far, you probably already know that “call” is a method of the Function prototype that executes its function in the scope of another object. Here, we’re executing slice in the context of our array-like object. Any remaining parameters to the call method are passed as formal parameters to slice. Here, calling slice with zero for the first parameter and no second parameter just tells slice to grab all items.

return function toArray(object) {

The line immediately above declares our toArray function as well as the formal parameter for our array-like object. The return statement indicates that we’re going to pass our toArray function’s reference somewhere. Of course, it’s going to be assigned to our top-level toArray variable, but first let’s investigate the first and last lines:

var toArray = (function (slice) {
   . . .
})(Array.prototype.slice);

Here, we’re declaring an anonymous function with one parameter, slice. Then we’re executing the function, passing it a reference to Array.prototype.slice. This is an easy way to declare and assign a local variable to the slice function in our anonymous function. (The parentheses around the anonymous function cure a syntax ambiguity.) Since we’re executing the anonymous function immediately (inline execution), we’re returning the value from the outer return statement (return function toArray) directly into the outer toArray variable.

In case you missed it: the outer function executes immediately, returning the inner function (toArray), which will be executed when we call our [inner] toArray function — the one referenced in the toArray top-level variable! (If this is your first time doing this crazy s**t, you better re-read that a few times.)

kangax brings up an excellent point. Debuggers don’t typically introspect very deeply (and certainly won’t grok this construct). Therefore, it is important to name any non-trivial functions (e.g. our inner function) so that the name can be shown in stack traces, etc. A stack trace full of calls to function () aren’t very helpful. However, it is also important not to name any functions that may pollute our global namespace (e.g. our outer, inline-executed anonymous function).

OK. Now that that’s settled, I will attempt to make our toArray function as small as possible. In the early 90′s when I worked with an APL programmer. He always claimed he could write a whole application in 1 line of code. It turned into a big joke around the office. But I guess I took it to heart. Here’s my attempt at the smallest, high-performance, non-polluting, general-purpose toArray function:

var toArray = (function(s){return function(o){return s.call(o,0)}})([].slice);

Go ahead. Beat that.

(Yah. I know I am breaking so many best practices here, but I just had to try it!)

OK. So why is this so important?

So what makes this better than just placing calls to Array.prototype.slice.call(obj, 0) all over your code?

Reason #1: Clarity. The reader doesn’t get bogged down by implementation details.

Reason #2: Speed. At execution time, there are less lookups by the Javascript interpreter (2 versus 4), but only one extra reference to a local variable (s). References to local variables are much faster than lookups. Lookups occur every time you reference a member (every “.” in dot notation) and every time you reference a global variable.

Reason #3: Light weight. Calling toArray(obj) yields smaller code than using Array.prototype.slice.call(obj, 0). It only takes 4 calls to toArray before your code starts getting smaller.

Reason #4: Understandable. You won’t perturb the Java Stoics who have to understand your code.