Main menu

Category Archives: performance

The AMD format for JavaScript modules was created to allow devs to write elegant, modular code rather than the silly global, name-spaced hackfest we’ve been writing. However, AMD has a hidden benefit: it allows modules to be downloaded in parallel, rather than sequentially. This is a potentially huge performance win.

Over the past several weeks, I’ve been writing an AMD-compatible javascript loader called curl.js. AMD stands for Asynchronous Module Definition and is a CommonJS proposed standard for writing javascript modules. The module format closely follows the proposed migration path set out by ECMA’s proposed ES-Harmony javascript modules.

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.

I’ve neglected this blog lately. My only excuse is that I am very, very busy! Not only have I been lucky enough to land a great opportunity working with some very bright jQuery Interactive Developers at Molecular, but I’ve also been working on something really big. (More on that later!)

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?

In my previous post, A Better Javascript Memoizer, some of you left some great feedback. (Thanks to all of you!) I think it’s because each of us has a different definition of “better”. That makes sense.

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.

Last month, I had the pleasure of meeting tons of excellent and intelligent front-end engineers at JSConf 2009 — the conference for Javascript in Washington DC. If you are a front-end engineer — or even if you write programs in Javascript for back ends, mobile devices, or desktops — you absolutely have to go to JSConf 2010. It’s apparent that Javascript is quickly becoming one of the hottest languages for all environments and applications, and JSConf is the first (and only) conference that deals with Javascript exclusively.

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.

(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?”

This should really be Tip #1 since it’s the most critical of all. Let me just say this as clearly as possible:

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.

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):Continue reading →