The good news is that Firefox 3.6 has this feature built in, though it takes a bit of work to enable. Apparently they’ve been trying to get this feature into Firefox since 3.0, but there’s been a lot of different opinions, so even though they finally shipped it with 3.6, it isn’t on by default. You can turn it on by going to about:config (just type that right into your address bar), then searching for “ctrlTab”. Double-click browser.ctrlTab.previews to turn it to “true”. Now, when you hit Ctrl-Tab, you’ll get a tab switcher that looks a bit like the default Windows Alt-Tab window switcher (though with a much lighter glass effect that honestly looks pretty bad compared to Windows’ Alt-Tab). On other platforms you’ll get a similarly system-integrated look. Unfortunately this popup isn’t exactly what we’re looking for – it doesn’t show all your tabs and you can’t search! However, you can navigate down to “show all X tabs” at the bottom and you get a search box and a list of every tab. That’s a real pain to do every time you want to switch tabs, though. Fortunately, there’s a solution. Instead of hitting Ctrl-Tab, use Ctrl-Shift-Tab, and you’ll start out right at the big tab switcher with search. From here you can type to narrow down your selection and hit Enter to choose your tab. I wish there was a preference to make this full search show up when you hit Ctrl-Tab, but it doesn’t look like there is.

Switching between tabs (man, that glass effect is a mess)

Visual issues aside, I wish every program with a tab-oriented UI had a feature like this to make their app faster to use for keyboard users. While we’re at it, Windows and OSX should add search to their built-in window switchers – it could really help when I have a lot of windows open and don’t want to reach for the mouse.

Note: There are a couple extensions for Google Chrome that theoretically give a similar searchable tab switcher, but of the few I tried, none of them could appear with a keyboard shortcut – you had to click an icon on the toolbar, which seems to defeat the point. Apparently the Chrome Extensions API has known problems with keyboard shortcuts, so maybe things will get better soon.

To get around this, I wrote a tiny, obvious little module that gives a simple syntax for caching objects with the file store. The trick is that it stores the insert time whenever it caches a new object, and compares it with the current time every time it looks it up. If the cached object is too old (or the cache is empty), it throws it away and executes the provided block and caches the new value.

Be sure to use the same expiration whenever you fetch the same object, or things will expire differently depending on where they’re accessed. You can also do a bit of customization for more complex cache invalidations – I have a version of fetch that caches objects within one calendar day and recalculates them only when the date is different. I suppose I could made fetch take an optional Proc to control the caching strategy, but I didn’t really need that much customization. Anyway, this isn’t exactly brilliant new code, but it has made caching objects from my smaller Rails apps a bit easier.

Again, the details are after the jump.

For reference, here’s the original implementation of jQuery.each from jQuery 1.3.2 (it hasn’t changed much for 1.4):

function( object, callback, args ) {
 var name, i = 0, length = object.length;

 if ( args ) {
  ... omitted ...

 } else {
  if ( length === undefined ) {
    ... omitted ...
  } else
   for ( var value = object[0];
    i < length && callback.call( value, i, value ) !== false; value = object[++i] ){}
 }

 return object;
}

I cut out some pieces relating to iterating over Objects instead of Arrays, and some internal-only code, just for brevity. You can see that at its core, each just iterates over the array with a regular for loop and calls the provided callback for each element. It’s using the call function to invoke the callback so it can set this to the value of each element in the array in turn, and passes the index in the array and the value at that index as parameters to the callback as well.

I ended up trying four different modifications of jQuery’s each function. I also allowed myself to actually change the signature of each, which would likely break much existing code written on top of jQuery, but it gave me a lot more freedom to tweak things.

The first was to try using native Array.forEach (where available). I had to pass in my own callback to forEach that reversed the order of the index and value arguments to the function, since jQuery.each and Array.forEach put those arguments in opposite order. Of course, I had to fall back on the original for loop implementation for IE. This modification retains the complete behavior from the original implementation.

if (jQuery.isFunction(object.forEach) ) {
  object.forEach(function(value, i) {
    callback.call(value, i, value);
  });
}
else {
  for (var value = object[0];
    i < length && callback.call(value, i, value) !== false;
    value = object[++i]) {}
}

Next, I tried skipping the callback that switches the order of arguments and just passing the user's callback directly to forEach. I had to modify the fallback to match this. Notice in both cases we no longer set this to the current element in the iteration - Array.forEach doesn't support that directly. We're solidly in non-backwards-compatible change territory here.

if (jQuery.isFunction(object.forEach) ) {
  object.forEach(callback);
}
else {
  for (var value = object[0];
    i < length && callback.call(null, value, i) !== false;
    value = object[++i]) {}
}

I noticed in testing this out that Firefox seems to really struggle with using call with a frequently-changing value for this (the first parameter) so I tried another variation that didn't use native Array.forEach but just didn't change this in the call (I let it be the whole array each time):

for (var value = object[0];
  i < length && callback.call(object, i, value) !== false;
  value = object[++i]) {}

After that, I wondered why use call at all (I might be missing something important here about how JavaScript function invocation works - please correct me!) So I tried a version that just called the callback directly.

for (var value = object[0];
  i < length &&  callback(i, value) !== false;
  value = object[++i]) {}

With these four variations, I went and tested how long it took for them to iterate over a 500,000 element array in different browsers. In the previous tests I used 100,000 elements but the tests completed too fast to get meaningful results (which should tell you how fast this stuff is to begin with!). As in the previous post, the absolute numbers don't really mean much - it's the comparison between the different approaches that matters.

We find that Firefox 3.6 improves over Firefox 3.5, IE is slow no matter what (though faster than Firefox 3.5 for vanilla jQuery.each), and the Webkit browsers are both very fast. What's more interesting is to look at each time as a percentage of the stock jQuery implementation:

A couple of things jump out at us - Array.forEach doesn't buy us anything if we have to provide a callback to reverse the inputs. If we can use the native forEach signature, it gets much faster, but not by an order of magnitude. Not varying this helps a lot in Firefox and Chrome - I suspect some runtime optimizations kick in if this stays the same, but not if it's changing. The overhead of call is significant - it tends to matter more than anything else here. The last thing to note is that, weirdly, Safari 4 is fastest with the stock jQuery.each - I wonder if they've optimized specifically for that pattern.

Armed with this knowledge, I customized a copy of jQuery 1.4 to stop referring to this in its uses of each, switched the for loop to call the callback directly instead of using call, and reverse-engineered the performance tests John Resig used for the jQuery 1.4 release notes. Using these tests, I compared my custom version to the released jQuery 1.4.

The result: optimizing array iteration speed made no difference. The real work being done by jQuery (DOM manipulation, etc) totally overshadows any array iteration overhead. Reducing that overhead even by 80% doesn't matter at all. We learned a few things about how fast Array.forEach is and how setting this in call affects performance, but we haven't found some magic way to make our code, or jQuery overall, any faster. Furthermore, the only improvement that would have preserved the signature of the original jQuery API was actually slower than the existing implementation! It's not worth losing this in each for any of these speed gains.

There was one small improvement to jQuery, however - a very small boost to the compressability of the library. Using explicit arguments to each instead of this to refer to the current element being iterated means that YUI Compressor or Google Closure Compiler can use one character for that item, instead of 4 for this (since this is a keyword). In practice, that saved about 197 bytes out of 69,838 - still not a huge win. But I like to avoid using this in my each anyway, just so I get to use semantically meaningful variable names, so it's nice to see that I'm saving a byte or two along the way.

PS: Aside from the "jQueryness" of it, I wondered why each set this to the current element in the array anyway. I have one idea - if this is set to the current element in the array for each invocation of the callback, you can do cleaner OO-style JavaScript. For example, let's say you have a Dialog object that has a close method. Of course the close method would just use this to refer to the object it's a member of. But if you had an array of Dialogs and wanted to say "$.each(dialogs, Dialog.prototype.close)" and each didn't set this to each Dialog in turn, everything would get confused. Of course, in jQuery 1.4 you can get around this using jQuery.proxy, which goes ahead and uses apply (a variant of call) anyway.

I’d also recently seen an article on Ajaxian about a new library, Underscore.js that claimed to include, among other nice Ruby-style functional building blocks, an each function that was powered by the JavaScript 1.5 Array.forEach when it was available (and degrading for IE). I wondered how much faster that was than jQuery’s $.each, and that got me to thinking about all the different ways to iterate over an array in JavaScript, so I decided to test them out and compare them in different browsers.

This gets pretty long so the rest is after the jump.

I went with six different approaches for my test. Each function would take a list of 100,000 integers and add them together. You can try the test yourself. The first was a normal for loop, with the loop invariant hoisted:

var total = 0;
var length = myArray.length;
for (var i = 0; i < length; i++) {
  total += myArray[i];
}
return total;

And then again without the invariant hoisted, just to see if it makes a difference:

var total = 0;
for (var i = 0; i < myArray.length; i++) {
  total += myArray[i];
}
return total;

Next I tried a for in loop, which is really not a good idea for iterating over an array at all - it's really for iterating over the properties of an object - but is included because it's interesting and some people try to use it for iteration:

var total = 0;
for (i in myArray) {
  total += myArray[i];
}
return total;

Next I tried out the Array.forEach included in JavaScript 1.5, on its own. Note that IE doesn't support this (surprised?):

var total = 0;
myArray.forEach(function(n, i){
  total += n;
});
return total;

After that I tested Underscore.js 0.5.1's _.each:

var total = 0;
_.each(myArray, function(i, n) {
  total += n;
});
return total;

And then jQuery 1.3.2's $.each, which differs from Underscore's in that it doesn't use the native forEach where available, and this is set to each element of the array as it is iterated:

var total = 0;
$.each(myArray, function(i, n){
  total += n;
});
return total;

I tested a bunch of browsers I had lying around - Firefox 3.5, Chrome 3, Safari 4, IE 8, Opera 10.10, and Firefox 3.7a1pre (the bleeding edge build, because I wanted to know if Firefox is getting faster). I tried testing on IE6 and IE7 in VMs but they freaked out and crashed. The tests iterated over a list of 100,000 integers, and I ran each three times and averaged the results. Note that this is not a particularly rigorous test - other stuff was running on my computer, some of the browsers were run in VMs, etc. I mostly wanted to be able to compare different approaches within a single browser, not compare browsers, though some differences were readily apparent after running the tests.

I've highlighted some particularly interesting good and bad results from the table (in green and red, respectively). Let's see what we can figure out from these tests. I'll get the obvious comparisons between browsers out of the way - IE is really slow, and Chrome is really fast. Other than that, they each seem to have some mix of strengths and weaknesses.

First, the for loop is really fast. It's hard to beat, and it's clear that if you've got to loop over a ton of elements and speed is important to you you should be using a for loop. It's sad that it's so much slower in IE and Opera, but it's still faster than the alternative. Opera's result is somewhat surprising - while it's not particularly fast anywhere, it's not nearly as slow as IE on the other looping methods, but it's still pretty slow on normal for loops. Notice that IE8 is the only browser where manually hoisting the loop invariant in the for loop matters - by almost 3x. I'm guessing every other browser automatically caches the myArray.length result, leading to roughly the same performance either way, but IE doesn't.

Next, it turns out that for in loops are not just incorrect, they're slow - even in otherwise blazingly-fast Chrome. In every browser there's a better choice, and it doesn't even get you much in terms of convenience (since it iterates over indices of the array, not values). Safari is particularly bad with them - they're 10x slower than its next slowest benchmark. Just don't use for in!

The results for the native Array.forEach surprised me. I expected some overhead because of the closure and function invocation on the passed-in iterator function, but I didn't expect it to be so much slower. Chrome and Safari seem to be pretty well-optimized, though it is still several times slower than the normal for loop, but Firefox and Opera really chug along - especially Firefox. Firefox 3.7a1pre seems to have optimized forEach a bit (probably more than is being shown, since 3.7a1pre was running in a VM while 3.5 was running on my normal OS).

Underscore.js each's performance is pretty understandable, since it boils down to native forEach in most browsers, it performs pretty much the same. However, in IE it has to fall back to a normal for loop and invoke the iterator function itself for each element, and it slows way down. What's most surprising about that is that having Underscore invoke a function for each element within a for loop is still 10x slower in IE than just using a for loop! There must be a lot of overhead in invoking a function with call in IE - or maybe just in invoking functions in general.

Lastly we have jQuery's each, which (excluding for in loops) is the slowest method of iterating over an array in most of the browsers tested. The exception is Safari, which consistently does better with jQuery's each than it does with Underscore's or the native forEach. I'm really not sure why, though the difference is not huge. IE's performance here is pretty much expected, since Underscore degrades to almost the same code as jQuery's when a native forEach isn't available. Firefox 3.5 is the real shocker - it's drastically slower with jQuery's each. It's even slower than IE8, and by a wide margin! Firefox 3.7a1pre makes things better, but it's still pretty embarassing. I have some theories on why it's so slow in Firefox and what could be done about it, but those will have to wait for another post.

It'd be interesting to try out some of the other major JavaScript libraries' iteration functions and compare them with jQuery and Underscore's speeds - I'm admittedly a jQuery snob, but it'd be interesting to see if other libraries are faster or not.

It's worth noting that, as usual, this sort of performance information only matters if you're actually seeing performance problems - don't rewrite your app to use for loops or pull in Underscore.js if you're only looping over tens, or hundreds, or even thousands of items. The convenience of jQuery's functional-style each means it's going to stay my go-to for most applications. But if you're seeing performance problem iterating over large arrays, hopefully this will help you speed things up.

Jeff Atwood (of codinghorror.com) has written about Swoopo multiple times, and some techies have even tried to game the system, but it hasn’t worked. I was introduced to Swoopo through Jeff’s blog but I hadn’t thought about it forever, and for some reason it came up again recently. After looking at it a bit, I was just floored by how they’ve managed to set up such a perfect money-generating system. The company that runs Swoopo is called “Entertainment Shopping”, which I guess is supposed to be a suggestion that it’s like gambling (where it’s “fun” to lose money) though they really, really don’t want to be regulated as gambling. I don’t personally find gambling (or bidding on Swoopo) to be that fun, but I do find it entertaining to watch the astronomical profits tick up as more and more suckers toss money into an auction. So I built a little Greasemonkey script that’ll add the estimated profit to Swoopo above the price of an auction, updating in real time as people place bids.

It took quite a bit of work to sniff out the prices from the page (I suspect they make it hard to scrape on purpose), but I’ve checked it out and the script works pretty well on current and recent auctions on all of Swoopo’s different sites (US, Canada, UK, Germany, Austria, and Spain). It won’t work on some of their older auctions, where the rules were slightly different (and bid costs were different, too). The basic formula looks like this:

((currentPrice - bidAmount) / bidAmount) * bidCost + currentPrice - worthUpTo

I’m calculating it with all the fairness to Swoopo I can muster. I calculate the number of bids based on the current price and the amount each bid moves the price (bidAmount) times the cost of bids (bidCost). The winner still has to pay the current price, so I add that in, but I subtract what Swoopo says the item is “worth up to” since they probably have to pay around that to drop-ship it to a customer. As the example screenshot shows, this leads to examples like an iMac selling for $364.75 (plus another $392.40 in bids for the winner), but a total pure profit of $9,827.98 for Swoopo. Exciting! I’ll readily admit that my calculation is not always 100% accurate. There are a number of things I don’t take into account – I assume shipping is a wash, so it’s not included. I assume Swoopo’s paying the full retail “worth up to” price when they’re probably not. I count bids as all costing the same even though they might have been won at a “discount” via a bid auction. In cases where I can’t figure out some numbers I default them to hardcoded values, which might be wrong. I also don’t take into account “Swoop it now”, which lets bidders buy the item for its full price minus the money they’ve sunk into bids, effectively getting out of the auction entirely. This would reduce Swoopo’s profits but it isn’t recorded anywhere so I can’t factor it in. So take the number with a grain of salt – it’s entertainment.

Grab the script and start poking around swoopo.com. Hopefully you’ll have as much fun as I have with it.

As a side note about my Greasemonkey scripts, I’ve retired the “Amazon Super Saver Snooper” script. Amazon has changed the way the API used to look up Super Saver eligability works, and I can’t get at that data anymore. More importantly, Amazon now puts “Prime” logos next to Prime-shippable items, so the script isn’t necessary anymore.