I does Javascript! » Performance

Palindromes

sstchur — Sat, 14 Jun 2008 19:06:11 +0000

The other evening while I was watching TV, I happened to have my laptop out, so I started dabbling around in Firebug just for the heck of it. I'll often just start writing functions for no particular reason, other than to refresh my skills or perhaps discover something about Javascript that I hadn't previously known.

So I was monkeying around, and I decided to write a function to determine if a string were a palindrome. This is not a very difficult problem, but it might make for a descent introductory interview question (one of those questions you'd ask to rule out the truly inept).

With problems like this, I'm mostly interested in two things:

Writing the function in a clever way, so as to achieve the least amount of code possible
Writing the function in the most efficient way possible

Now, if it were Ruby, writing the clever solution (which might also happen to be the most efficient solution in that language -- not sure) would be ridiculously easy:

def pal(s)
s == s.reverse
end

That's so trivial, it's probably not even worth writing.

But Javascript doesn't have a .reverse() method on strings, so you have to take an extra step (still pretty easy though):

function pal(s)
{
return s === s.split('').reverse().join('');
}

Split the string into an array, reverse the array, and then join it back together. Since this is all native Javascript stuff, it turns out to be reasonably fast, though one might expect you could do better.

For grins and giggles, I decided to see how a manual solution, where I compare characters starting at each end of the string and work towards the middle, would compare:

function pal(s)
{
var i, j,
len = s.length,
mid = Math.floor(len / 2);

for (i = 0, j = len - 1; i < mid; i++, j--)
{
if (s.charAt(i) !== s.charAt(j)) return false;
}
return true;
}

This function will probably fail quickly, so that's good, but it also turns out to be generally faster than the split/reverse/join version. It makes sense, since you're going through the string only one time and twice as fast as normal since you're traversing from both ends at the same time.

Can you do even better though? Maybe. At least in Firefox you can, and quick tests seemed to confirm across other browsers too (but I didn't test extensively).

What if we split the string in half, and only reverse half of it. Then we can compare the first half with the original half:

function pal(s)
{
var len = s.length,
x = len / 2,
y = x === Math.floor(x) ? x : (x = Math.floor(x)) + 1;

return s.substr(0, x).split('').reverse().join('') === s.substr(y,len);
}

The idea here is just split the string in half, reverse one of the two pieces and compare them. For example:

TOOT: splits into "TO" and "OT." Reverse one of them, say the second part ("OT") and compare.

If you've got a odd number of characters, you can ignore the middle most character:

RACECAR: splits into "RAC" and "CAR" (ignore the "E" in the middle). Reverse the second part ("CAR") and compare.

As it turned out, this seemed to be faster than the other two methods. Not by orders of magnitude, but not insignificantly either. Here are the number from Firefox, running each function 10,000 time on the string "gohangasalamiimalasagnahog" (go hang a salami, i'm a lasagna hog).

(Traverse from both ends): 797ms
(Split/Reverse/Join): 969ms
(Compare halves): 640ms

Of course, numbers varied slightly during each run, but overall the they were consistent relative to each other.

So there ya go. Nothing in particular I wanted to point out here; just found it interesting and thought you might too.

Think my code sucks? Got a better solution? Say so in the comments (you won't hurt my feelings).

Clean up after your event listeners

sstchur — Thu, 06 Sep 2007 06:01:02 +0000

Memory leaks in Javascript are, unfortunately, a very real problem. Of course, it seems to be a problem mostly in IE (try disabling all add-ons if you think you're seeing them in Firefox). While there are a number of ways that memory can be leaked, I find that one of the most significant (and most frequent) causes is failing to remove event handlers.

Important Update: I failed to mention when I originally wrote this post, that you should use caution with this 'unload' technique. If you are manually unhooking events throughout the life of your web-app (or taking care to manually unhook them on 'unload'), then you might potentially be adding multiple (and unnecessary) 'unload' handlers to the browser.

This might not seem like a big deal, but in a large and complex app it can actually increase memory consumption dramatically, thereby negating any gain you'd have gotten from the technique!

Auto Detach with 'unload'

In IE, if you wire up an event listener and fail to remove that listener when your page unloads, you're probably asking for a leak. One effective technique to ensure that listeners get removed is to wire up an 'unload' event to the window which detaches the listener for you. For example:

var elem = document.getElementById('someElem');
elem.attachEvent('onclick', elemClick);
window.attachEvent('onunload', function(e)
{
elem.detachEvent('onclick', elemClick);
});

Keen readers might have noticed that I solved one problem (removing the 'click' listener from elem) by creating another one (attaching a new, anonymous listener to the windows's 'unload' event).

Why is this a problem?

In a previous blog entry, I mentioned that it wasn't possible to remove an event listener if that listener were anonymous, as in:

// IE specific code
var elem = document.getElementById('someElem');
elem.attachEvent('onclick', function(e)
{
alert('you clicked it!');
});

elem.detachEvent('onclick', function(e) // WON'T WORK!
{
alert('you clicked it!');
});

While it's true that the above code won't work, it's not entirely true to say that it's impossible to remove an anonymous listener. Why? Because every function actually has a reference to itself through its own arguments object. Specifically, through the .callee property of the arguments object.

We can use this to our advantage to detach the anonymous 'unload' listener from within the listener itself.

var elem = document.getElementById('someElem');
elem.attachEvent('onclick', elemClick);
window.attachEvent('onunload', function(e)
{
elem.detachEvent('onclick', elemClick);
window.detachEvent('onunload', arguments.callee); // detach this anonymous listener
});

Why not just un-anonymize?

You certainly could just name all of your functions and then refer to them by name, but sometimes anonymous functions are very useful since they allow to create closures and do other nifty Javascript tricks. In those cases where it's desirable to use an anonymous function, this technique might be just the ticket!

Conclusion

I've conveniently (for me anyway) left out any non IE-specific code in this post. It's worth nothing that I don't generally use this technique except in IE, which means a little cross browser code is in order to ensure that this 'onunload' technique is only used for that browser.

Of course, it isn't going to hurt anything for other browsers (and it might even help) so there'd be no harm is using it across the board, bu you'll still need to write some cross-browser code (obviously). I'll leave that as an exercise for the reader though.

Happy scripting.

Comments welcome.

Avoiding recursion in Javascript

sstchur — Fri, 06 Jul 2007 19:41:57 +0000

Recursion can often lead to elegant and short solutions (one of the reasons I like it so much), but it can, most definitely, be misused.

Learning recursion in school

I think just about every computer science course I've ever taken that (even remotely) mentions recursion, uses either factorial or Fibonacci as the starter sample to help students gets their heads around the concept. This is okay (I guess) as long as it's made clear that recursion is not the optimal solution for either of these.

It was in fact made clear to me in school that recursion is not ideal for factorial and Fibonacci, but for some reason that didn't stop me from using a recursive factorial function once.

function fact(n) { return n <= 1 ? 1 : n * fact(n-1); }

This, it turned out, was not just a bad decision; it was a horrible decision.

Idiot me

I'm not proud of it, and I'm still not entirely sure what possessed me to do it (especially knowing full-well that the iterative solution is better). Maybe it was my love of short, simple, readable code, or maybe my brain was just malfunctioning that day (but I tend towards the former; it's gotten me into trouble before).

In fact, if I remember correctly, the exact thought that went through my head that day went something like this:

You know... I remember learning that a factorial function should never be written recursively (except perhaps as a teaching example) because the iterative solution is much more efficient. But if I use recursion just this one time, I can get this nifty, one-line factorial function, and it looks just oh so pretty! Plus, I won't be using this function very often at all, so I don't think it will matter much.

Boy did that (horrible) rationalization miss the mark! It did matter, it mattered a lot. And to make the situation worse, I did end up using the function often (very very very often, and that might be an understatement).

Why so many factorials?

Our profiling tool indicated that the factorial function was being invoked over a million times! Whoa, now that's not good. Did I mention this was all in Javascript? Yeah, it was, so it's even worse.

So why all the factorials? Well, I was doing some fairly complex math involving Bezier curves. Part of that math involves Binomial coefficients which is defined as:

n! / (k! * (n-k)!)

The net effect of this was (roughly) a 7 second delay in the PLT of the particular page in which this script was running. Again, not good.

Lesson learned

So, as quickly as I could, I removed that dreadful (but pretty) one-line, recursive factorial function (hoping no one would notice) and replaced it with an iterative one. This boosted performance tremendously -- only took about 400ms to perform the same calculation.

Feeling so guilty for having made the poor decision to use recursion in the first place though, I still wasn't happy with my 400ms solution. I decided to see what else I could do to improve the performance. Turns out I was able to do some pre-computation and get the entire time down to about 48ms!

Ah, now I feel redeemed.

Heed this warning

So let this be a lesson to you: Use recursion wisely, only when appropriate, and in the case of Javascript, almost never!

Comments welcome.

IE innerHTML Memory Leak

sstchur — Wed, 16 May 2007 16:04:11 +0000

Kristoffer Henriksson has got to be one of the most intelligent people I know. His ability to write, test, and debug code is second the none. Heck, I wouldn't be surprised if the guy can read and write machine code as if it were English.

Recently, Kristoffer did a significant amount of investigation to track down a nasty IE memory leak issue. IE's problems with memory leaks are well known, but most of the time, you'll hear people saying things like "closures are the cause of memory leaks," or "failing to detach events is what causes memory leaks," and (probably the most common), "circular references are the culprit -- they cause memory leaks."

To some degree, all of these things are true. Closures can sometimes lead to memory leaks, failing to detach events can also lead to memory leaks, and yes, circular references to DOM elements can also be the cause of memory leaks.

One kind of leak that seems to get a little less attention though, is the one involving .innerHTML. Fortunately (thanks to Kristoffer's investigation) this one is pretty easy to deal with.

Before we can deal with the leak, we need to understand what causes it. Three conditions are required:

A orphaned DOM element must exist in memory.
That element's innerHTML must be set to a string of markup the creates an element with some DOM 0 event wired up.
The aforementioned innerHTML property must be set before the orphaned DOM element is "unorphaned" (added to the page).

If these conditions are met, get ready to call the (Javascript) plumber, because you've got a leak!

To make things a little less abstract, I'll write some code and explain piece by piece, how it fits the conditions above:

// 1. An orphaned DOM element must exist in memory.
var elem = document.createElement('div');
// poor elem is just floating around in the page's memory without a parentNode

// 2. elem's innerHTML must be set to a string of markup that creates an element with some DOM 0 event wired up.
elem.innerHTML = 'Test Link';
// elem contains an tag with an onclick event

// 3. elem is now added to the page, after innerHTML has already been set.
document.body.appendChild(elem)
// elem (and its child tag) is now part of the page (remember, that innerHTML has already been set)

As you can see, the code above is not at all an uncommon scenario. Chances are though, if that's all you've got, you won't notice much of leak. This issue really only manifests itself when multiplied, that is, when you set .innerHTML in the above manner over and over and over again on the same page.

Why would ever do this? Think Web 2.0, think AJAX, think dynamic page updates and you probably won't have to search too hard to find a situation where someone might do this. Maybe you already know of (or helped write) a Web 2.0 app that does this.

Memory Leak Demo Page

Anyway, when above pattern is multiplied (whatever the reason) memory leaking chaos will ensue. To illustrate the problem, I've put together a sample page with a script that creates a orphaned

element, whose .innerHTML is set to a string of 2000 tags with onclick events. When you click the "Start Leak" button, the script executes repeatedly, until you click the "Stop Leak" button. This give you a chance to use Perfmon to monitor memory consumption and see the results of the leak. The memory leak demo page can be found here.

The solution

It turns out, the solution is actually pretty easy: simply make sure to set .innerHTML after appending the DOM element to the page. That's it!

// create the element in memory
var elem = document.createElement('div');

// add it to the page before setting .innerHTML
document.body.appendChild(elem)

// now it's safe to set .innerHTML
elem.innerHTML = 'Test Link';

Of course there are other solutions, one of which is to avoid using .innerHTML at all. As a general best practice, I encourage this (for a number of reasons that I don't have time to get into here), but I recognize that that suggestion may not also be desirable, or practical.

To see that this really does take care of the issue, I've put together another test page. In this one, the .innerHTML property is only set after the DOM element has been added to the page.

If you click the "Start Leak" button on each page and let it run for about 60 seconds or so, you should notice that the first page continues to consume more and more memory as time goes on, whereas the second page's memory consumptions remains relatively constant.

Demo Links

In case you're the kind of person who doesn't like to read paragraphs to find embedded links (I'm like that), here are the links to the two demo pages, for your convenicne:

So there ya go: a nasty bug, but thanks to Kristoffer's work tracking tracking down the exact causes of this leak, a fairly easy one to handle.

Comments welcome.