Erik's blog

I work in the core-gfx team here at Opera and are currently working on our WebGL implementation. I've only been with Opera for a little less than two years following a far too long time in the games industry. So far I'm loving every minute in the browser business.

I've been working on a WebGL demo on my spare time for a while and just like I've always been doing when writing games in C++ I wanted to have my assets all neatly wrapped up in a zip archive.

It's very handy, reduces disk footprint, loading time, organizes your files and above all with shell/explorer-integration it's so easy to work with even your most technology ignorant artist, designers and producers can handle it.

Since I couldn't find any javascript library that did that for me I decided to write one myself. I took the excellent C library tinf (tiny inflate) by Jørgen Ibsen, spent a few hours porting it to javascript, a few more to work out why my ported pointer arithmetic didn't work, added a bit of PKZIP archive management source and voila.

It worked like a charm... in Opera. Now, this is where the story takes a turn. This post isn't about my seriously cool WebGL demo, or about how great my little JSUnzip library is, it's about javascript performance and whether Crockford is right in that we're all so busy tuning our browsers to SunSpider and the likes that real-world implementations suffer.

JSUnzip is a straight port of one of the most widely used applications in the world. So if SunSpider, Kraken and V8 are truly indicative of real world performance I'd see the browsers all perform within a reasonable range of each other when unpacking the Canterbury Corpus zip. They didn't. In fact the numbers were so off that I instantly assumed something was wrong with the test. Firefox clocked in at 10 times slower than Opera, Chrome at 60 times slower and Safari at a whopping 100 times slower. (I really tried my best at including IE but it just won't work with XHR and binary data. If you know how to make it, let me know!) When you see results like these you immediately expect them to be wrong, but I both double and triple checked them, verified output, ran it over and over again and asked colleagues to check it out. Intrigued by the results I decided to see if I could zone in on the performance hotspot. The easiest would be the two webkit browsers since they were by far the ones suffering the most. A few hours later I had distilled the inner loop and came up with this test case.

// Hotspot testing. Backreference copy.
var dest = 'apple';
while (dest.length < 100000) {
    var offs = dest.length - 5;
    for (var i = offs; i < offs + 10; ++i)
        dest += dest[i];
}

It's a dead simple inner loop which is something you see in the deflate algorithm. It copies an earlier occurrence of characters from a string and adds it to the end.

You can try the live test-case in your favourite browser here: webkit hotspot test-case.

When I ran it on my box I got these results:

Firefox 4.01         -    8ms
Opera 11.10          -   13ms
Internet Explorer 9  -   26ms
Chrome 11            - 2230ms
Safari 5.05          - 4685ms

Apparently this was not the same hotspot that Firefox hit in the full unzip test as it's soaring through this, but it's spot on for Chrome and Safari. For this dead simple little test we're seeing the fastest browser being more than a factor 500 faster than the slowest one. That's pretty significant. So what does this mean? Not a whole lot in the second browser war at least. I'm sure you could construct more of these where the results would single out another browser. The notable thing though is that my unsuspecting real-world usage hit such a significant difference between browsers when we're currently battling it out in media over milliseconds in SunSpider. Is Crockford right? Maybe. In any instance I don't think it would hurt to revisit the javascript performance test suites.

WebKitters, please optimize that hotspot so I can use JSUnzip in my demo and while I'm on the air, kudos to the Opera ES-team for Carakan, Opera's awesome JS engine. As always it's taking names and kicking ass.