Comparing Browser JavaScript Performance

Thwomp writes "Over at Coding Horror Jeff Atwood has an interesting writeup on JavaScript performance in the big four browsers. He used WebKit's newly announced SunSpider to produce the results. If a probable anomaly in the IE7 results is overlooked, Firefox 2 is the slowest of the bunch. Atwood has also benchmarked the latest Firefox Beta, and its performance seems to be improved significantly."

Comments

A grain of salt

[pwnies]

Take note of the tests for the latest Firefox beta though, notice that he's using a different system with .2Ghz more and he's on a 64 bit system versus a 32 bit. Although it's not a huge leap, it IS a difference. Different system different benchmark.

Re:A grain of salt

[Mini-Geek]

Take note of the tests for the latest Firefox beta though, notice that he's using a different system with .2Ghz more and he's on a 64 bit system versus a 32 bit. Although it's not a huge leap, it IS a difference. Different system different benchmark.

Yes, it's a different system, so you shouldn't compare that FF3 number to the IE/Opera/Safari numbers, but you can still compare it to the FF2 number there (BTW that FF2 number is even a little slower than the one that all tests were run), which obviously shows that it's faster.

Re:A grain of salt

[philwx]

Try a heads up between Firefox and IE after the average-joe user has had a few weeks to accumulate spyware.

I'd like to see those results.

Re:A grain of salt

[Jeffrey Baker]

I think this "benchmark" is deeply weird. It only exercises the pure execution paths, while pretty much ignoring all of the data structures that make a web page work. Every web app I've written or tried to optimize is limited not by time spent in javascript, but rather time spent manipulating the dom and drawing.

I guess there's value in such a benchmark, but it goes against the conventional wisdom of Amdahl's Law. If JS execution accounts for only 10% of the runtime of your application, it will be of little value to make JS 20% faster. You must concentrate on the other 90%.

Re:A grain of salt

[Rei]

Well, it depends on what your app is doing, I suppose. If it's just a bunch of onClick statements that have simple responses, sure -- I wouldn't expect much time to be spent in it. On the other hand, I write asynchronous CGI and Javascript applications like this solar power economics calculator. And there's a *lot* of Javascript in there. Boosting Javascript performance is a big deal in such circumstances.

Re:A grain of salt

[Evil Adrian]

That's a pretty pathetic attempt to cover up a flaw in Firefox problem. Firefox is not better than IE in all things, and this is a clear example. Just admit it is a problem.

Do it. Admit it. It's ok, the world won't end.

Re:A grain of salt

[Jeffrey Baker]

I just profiled your page with Venkman and it seems that > 96% of the CPU time is spent in document.getElementsByName. Were you trying to prove my point?

Re:A grain of salt

[KingMotley]

I realize that it's too much to ask to have people read the whole article on slashdot, but it's unexcusable that the author of the article didn't take the 30 seconds to investigate a problem he's having before posting his drivel.

It could be that some of the test scripts were actually written by Mozilla, and uses some non-standard javascript functions that are causing errors in IE. By non-standard, I mean uses proprietary extensions to the ECMA-262 specification, which is *EXACTLY* what these benchmark scripts are doing.

In particular, they are referencing characters within a string object by using array syntax, which isn't valid according to the specification. The correct way to retrieve the character at a particular location within a string is by calling the charCodeAt function. Once these non-standard calls are corrected, IE vastly out performs FF. Of course these errors are causing IE to generate a huge string "undefinedundefinedundefinedundefined..." (Not to mention all the error processing overhead), which is apparent if you actually look at the output of the functions. On my machine, IE runs the corrected code just under 30 times faster.

Re:A grain of salt

[fatphil]

He also doesn't have a clue how to combine benchmark results. Unless the individual sub-tests are deliberately weighted, you shouldn't use an arithmetic mean (or a sum), instead you should use a geometric mean. A sum without weighting gives more importance to tests that run for longer, which clearly biases the final result.

Re:A grain of salt

[AmberBlackCat]

I would think taking up more of the available memory would just give IE more of an advantage over Firefox.

Re:A grain of salt

[othermaciej]

The author of the article didn't make the benchmark, I did.

Re:A grain of salt

[othermaciej]

Oops, premature post. The author of the article didn't make the benchmark, I did. The sub-tests are in fact deliberately weighted to take similar times and be reasonably representative of different aspects of the JavaScript language. Specifically, the individual sub-tests were calibrated to take about the same amount of time as each other in the most popular browsers, excluding browsers that were a sole outlier on a particular test. Using a geometric mean would give the result that a browser that took 1 second to do task A and 1 second to do task B would score the same as a browser that took .25 seconds to do task A and 4 seconds to do task B. It's not obvious to me that this is the case; I tend to think it isn't. (Test bug with string indexing acknowledged, but it only affects one of the sub-tests afaik. It will be fixed in a future version of the benchmark. There's a reason I posted it for public review before publishing any competitive numbers myself.)

Re:A grain of salt

[Bitsy Boffin]

No, he just showed that sadly like the majority of developers, he is unable to distinguish between LANGUAGE and API, at least when it comes to javascript (language) and dom (api) - it is evident all the time when people cry that they hate javascript because they can't get X bit of dynamic html to look right in all browsers, they don't see or understand that Javascript has nothing to do with that, it's the API, the DOM that is causing the grief.

As you say, when it comes to speed, especially with something like JS+DOM it's not the language that's the problem because the language isn't actually doing a hell of a lot unless you're going to be doing some major number crunching or something, it's the api calls that take the time (in application programming land, the syscalls).

Any benchmark of JS+DOM needs to weigh heavily on the DOM part of that pair to be of any real help.

Re:A grain of salt

[KingMotley]

The author of the article spent the time to make pretty graphs, and even identified a oddity, but spent no time actually investigating it before publishing his article. I can easily say that it took me less than 15 seconds to spot the problem, and when I can figure it out with such little effort, I have to disqualify the entire rest of the article as garbage.

I understand that the code is supposed to represent "real world" code, but it's apparent that a lot of it wasn't tested very well, let alone be taken from something actually running somewhere, which is misleading. In any case, I've only taken a quick look at the string-base64 test, and string-validate-input. Base64 was producing errors in IE, and validate-input is extremely poorly written. In your test results of catching improper zip codes, it will repeat the error message for each letter within in the zip code. For example "12345xyz" will produce 4 error messages, 3 messages that say "12345xyz contains letters", and one that says it's too long. A good routine would first check the length to make sure you aren't getting 2GB worth of data in the field before trying to loop through. When it does loop through, it would exit the loop after the first error rather than generating multiple error messages that are exactly the same. That said, the test does stress strings, and someone might actually use code similiar in production, but I'd have any of my programmers shot for writing it. Is it a valid test? Perhaps. Just because it's code that shouldn't be running anywhere doesn't invalidate the fact that the functions it does perform better or worse than anothers.

Re:A grain of salt

[hey!]

A larger grain of salt is that weighting each of the benchmark components equally is sure to result in a score with very poor correlation on any real world application.

Lets assume for a moment the IE7 string result is a bug in the test rather than an IE7 itself. Nonetheless, this, along with property access, is bound to be a lot more important than 3D related operations for typical applications.

For that matter, the most important factor for Ajax applications would intuitively be marshaling and searching the DOM tree, which is not something the benchmarks reflect at all. If Javacript is not the bottleneck, it doesn't matter that product A has faster Javascript than B.

In fact, with a few exceptions like PDAs and very old machines in the Pentium 90 class, it doesn't matter very much if one Javascript is faster than another. Since most Javascript is mainly UI code (excepting maybe Google Web Toolkit?) what we care about is whether Javascript does its thing sufficiently fast that a user wouldn't notice it working. In other words we want the user's perceptual processes to be the bottleneck.It is possible to construct scenarios where Javascript performance is a serious problem, but the question is whether anybody is experiencing these scenarios?

Of course, all things being equal, faster is better. But faster isn't automatically better unless users of Javascript applications are experiencing problems. It seems to me that unless that is the case, the most important thing about any javascript implementation is how perfect its adherence to the standard is. The only people whom Javascript implementations commonly cause problems for are developers whose application doesn't run on their users' browser. This could happen because the user's browser doesn't support the standard, or the developer's primary target browser encourages him to use non-standard features.

So all in all, I see worrying about Javascript benchmarks as a waste of time for most developers and users.

Re:A grain of salt

[buddyglass]

I've definitely encountered pages where JS seemed to be the bottleneck. ESPN's "player" pages come to mind. As far as I can tell they compute certain aggregate statistics "on the fly" when generating the page. Maybe that's not what's happening, but from a user's perspective I notice my CPU spike whenever loading one of these pages along with an approximately 2s delay before the page is displayed and becomes scrollable.

Hmmm

[ubrgeek]

> if a probable anomaly in the IE7 results is overlooked

Like what? It didn't crash the system or it actually launched ;)

Re:Hmmm

[jrumney]

The "probable anomaly" is that it is an order of magnitude slower than every other browser at string operations, which are a kind of important feature of Javascript. I'm not sure why he sees this as a probable anomaly, but not any other result where one browser does a lot worse than the others (no browser appears a clear winner or loser on everything, though Opera does come out in front more often than the others).

Re:Hmmm

[chrb]

He says: "What surprised me here is that Firefox is substantially slower than IE, once you factor out that wildly anomalous string result."

To paraphrase: "What surprised me here is that Firefox is substantially slower than IE, once you manipulate the experimental data by removing something that IE is particularly slow at."

And guess what? If you remove string ops, bit ops, and date ops, then Firefox is probably faster than IE. ;-)

Re:Hmmm

[gazbo]

Exactly because it's an order of magnitude slower. In all other tests it is a similar speed to all other browsers, then in one particular test it is ridiculously slower. There are no other tests or browsers that exhibit this behaviour, else I expect he'd have discounted them as anomolous also.

There could be a good reason for the test showing poor performance - say IE is shit at string concatenation - and then the result reflects badly on IE. Or, it could be that for whatever reason the benchmark hits some strange edge case that virtually never crops up in normal usage, in which case the benchmark should be thrown out. But without further information you have to just treat the result as null. It's an unknown.

Re:Hmmm

[_xeno_]

IE's string concatenation is ridiculously slow. I've found that in all browsers (except Firefox) it's faster to use an Array, push() together the string elements, and finally join('') them together to create the final string.

In Firefox, this is ever-so-slightly slower. In Internet Explorer, it's a good order of magnitude faster. (Depending on the length of the string. Concatenating a string 100 chars long together 10,000 times, I got a time of 13.7 seconds for plain old string concatenation ("string" + "string") versus .04 seconds for Array.push(). Firefox did the same test in .7 seconds using both methods.)

The SunSpider tests appear to be using plain-old string concatenation. I'll have to try rewriting them using Array.push() and see what the result is. Doing that IE's performance would almost certainly beat Firefox.

Re:Hmmm

[morgan_greywolf]

IE wouldn't be faster than that much faster than Firefox 2, and no faster than Firefox if we 'filtered out' this anomalous reading. Assuming the string operations took 1.5 seconds (a nice round number in between Firefox's and Opera's times), we could subtract 12.9 seconds from IE's overall time of 21.2 seconds and arrivate at 8.4 seconds, putting it neck-and-neck with FF3 and still less than 25% faster than FF2's performance. FF2 is slow, but he makes it sound like FF2 sucks badly and it's just not that bad.

That being said, one can't be sure that IE7's string reading was 'anomalous' without significantly more data.

Also, I wouldn't make that much of the difference between Vista 32 and Vista 64 or between a 3.0 Ghz and a 3.2 ghz Core 2 Duo. Browser performance is likely extremely similar on both systems for all browsers, with the possible exception of IE7's (I have a sneaking feeling the 'anomalous' reading is an issue particular to 32-bit Vista)

Re:Hmmm

[Anonymous Coward]

At that point you wouldn't be testing string concatenation.
But yes. Dropping stuff was silly, not testing most of stuff javascript actually needs to do in a web browser was silly.
Here is some equal sillyness.

Windows->VirtualBox->Linux->Wine->Internet Explorer 6
Minimised the window and checked back once my CPU stopped crawling.

FF3

BS IE results

Re:Hmmm

[wickedskaman]

Why was this modded Redundant? I think this is a really valid point. All the Firefox fanbois hush up the fact that it has hogged more resources and crashed significantly more since the last non-beta update. At least this has been true in my case...

Re:Hmmm

[mulveling]

I've done some work before that required concatenating very large strings in Javascript, and the code was certain to be run in IE by our users. It was clear to me from the observed performance, that when you use the "+" or "+=" operators to build a large string from many smaller strings, IE does not attempt to optimize things under the hood with a String Buffer. In fact, *every* "+/+=" operation seems to allocate an entirely new String object to contain the result. Problem is, most of those Strings are intermediate results that will just end up get tossed by the garbage collector, and hence their allocation was for naught. A quick analysis of this means that we're looking at a total memory allocation cost on the order of N*N, which leads to very unreasonable performance when you're looking at concatenating 1000+ strings. From scanning the SunSpider string benchmarks, it looks like the specific benchmarks that IE has trouble with are indeed using the +/+= ops to build big Strings.

Fortunately, there are workarounds. The easiest is put all the component strings you wish to add together into an array and then call join('') on the array to build the result string. This executes much, much faster in IE and should be fast in the other browsers as well. Before I figured out the join('') "trick", I implemented a scheme to add the component strings in a much more optimal order...the N^2 cost is only if you add them in a naive, left-to-right manner. By pairing up adjacent components and adding, you get N/2 intermediate results. Repeating the pairing process on these intermediates, and over again until you have your 1 final result, the allocation cost is only N*Log(N), which is far FAR better than N*N. Incidentally, this is similar to the "Russian Peasant Algorithm" technique used to optimize the addition of N numbers on massively parallel processors...whereby you can reduce the cost of N additions from N to Log(N) time assuming there are enough processors (N/2) on hand. When I learned about the join(), I compared its performance to the Russian Peasant technique and got very comparable results in IE. Weired, since if join() were using a StringBuffer under the hood (like it should), then its performance should be O(N), not N*Log(N)...

Anyways, in summary - yeah it sucks hard that IE does that, but it's easy to workaround once you know what's up (gee, that's true in so many cases with IE quirks).

Re:Hmmm

[smittyoneeach]

This is speculation, but I think that the browser may use the COM MicroSort VBScript Regular Expressions 5.5 library, at c:\WINDOWS\System32\vbscript.dll, for doing regular expressions.
If that's true, (and I figure someone will calibrate me if I'm wrong) that could explain an apparent performance anomaly, if the browser farms out the string manipulations to another process.

Re:Hmmm

[tdelaney]

I can attest to IE's crap string operation performance.

4.5 HTML file, mainly consisting of one very large table. Took about 1 minute to render in IE, using about 80MB RAM. Was asked to lay it out in a more useful way. I went the fairly simple route - once it was fully loaded, I used JavaScript to lay it out better.

Original attempt was to just use innerHTML and string operations (couldn't remember the DOM commands, too lazy to look them up). The main bit was a single substring() on the div containing the large table (actually stripped off everything around the table).

The time to render the page jumped to 10 minutes! Memory use jumped sharply as well (largely because I was duplicating the table ... d'oh!). Cutting out that single substring operation dropped it back to 1 minute. Changing over to DOM manipulation left it at 1 minute.

For comparison, Safari 3 on Windows rendered the entire page in 5 seconds, whether I used innerHTML and substring() (including the duplication mentioned above) or DOM manipulation. Safari used a bit more memory than IE though (worst case 215MB compared to 200MB).

Re:Hmmm

[felix9x]

I remember doing this for work. We needed to create a select element with a few thousand items that needed to be added dynamically based on an array of data. The fastest way that worked across all browsers was to concatenate a strings of tags using Array.push and join() followed by adding the string to the select element with innerHTML. This was about 10 times faster in IE as opposed to adding option items using DOM methods.

Re:Hmmm

[Anonymous Coward]

The missing overhead is probably in IE's array ops, then, pushing and then looking up those strings in the first place...

Re:Hmmm

[nog_lorp]

Info from the JScript coders, on an MSDN blog: http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx (Linked in TFA)

Re:Hmmm

[cheater512]

A DLL call wouldnt make that big of a difference.
Its still the same thread.

More than likely is that they were using math operations which were already optimized and wrote their own string functions and then 'forgot' to optimize them.

Re:Hmmm

[afidel]

Wow, not all web developers are webmonkeys, at least one actually paid attention in CS class =) kudos.

Re:Hmmm

[KingMotley]

Or it could be that some of the test scripts were actually written by Mozilla, and uses some non-standard javascript functions that are causing errors in IE. By non-standard, I mean uses proprietary extensions to the ECMA-262 specification, which is *EXACTLY* what these benchmark scripts are doing.

In particular, they are referencing characters within a string object by using array syntax, which isn't valid according to the specification. The correct way to retrieve the character at a particular location within a string is by calling the charCodeAt function. Once these non-standard calls are corrected, IE vastly out performs FF.

IE is performing badly because it's generating a huge string "undefinedundefinedundefinedundefined...", which is apparent if you actually look at the output of the functions. On my machine, IE runs the corrected code just under 30 times faster.

Re:Hmmm

[n0-0p]

For someone that's complaining about misinformation, you really need to stop spreading it yourself. The benchmark was written by a Webkit dev, not a Mozilla dev. Taking cheap shots at an innocent third party doesn't help anyone. That stated, you have a completely valid point that the base64 benchmark is inaccurate. However, IE still has documented issues with string concatenations, which does account for weaker performance in string handling, just not the orders of magnitude difference that this test shows. Either way, this benchmark is not a good indicator of real-world performance, as many people have pointed out. Most web sites are more bound by the DOM interactions and layout than anything else.

Re:Hmmm

[KingMotley]

Taken from the source in question:
* The Original Code is Mozilla XML-RPC Client component.

also you can find the exact same code here:
http://lxr.mozilla.org/mozilla/source/extensions/xml-rpc/src/nsXmlRpcClient.js#956

Ooh ooh let me guess

[The MAZZTer]

With NoScript, Firefox's performance easily soars above the rest?

Re:Ooh ooh let me guess

[greg1104]

Yeah, what's far more important to me than "how fast does this browser run Javascript?" is "how easily does the browser non run Javascript?"

Re:Ooh ooh let me guess

[A Friendly Troll]

Yeah, what's far more important to me than "how fast does this browser run Javascript?" is "how easily does the browser non run Javascript?" As far as Opera goes - press F12, uncheck "Enable JavaScript".

Then whitelist sites you trust through site preferences.

Vista + ie7 took hours!

[mseidl]

<html>
<body>
<script type="text/javascript">
var i=0
for (i=0;i<=10;i++)
{
document.write.UAC("Cancel or Allow?");
document.prompt("Yes, No, Maybe?);
}
</script>
</table>
</body>
</html>

Re:Vista + ie7 took hours!

[VGPowerlord]

Nah, they just used document.confirm, but changed confirm to allow Yes/No with am undocumented second argument!

Opera

[QuietLagoon]

Looks like they are finally getting their javascript act together. After being a sore point for so many years, a working javascript in Opera will be welcome.

Re:Opera

[whitehatlurker]

Each of the individual tests work under Opera 9.25.

There is an error in the aggregating mechanism of the benchmark. Otherwise, it would work in the current Opera as well.

Re:Opera

[ed.markovich]

Looks like they are finally getting their javascript act together. After being a sore point for so many years, a working javascript in Opera will be welcome. I am just curious as to what you're talking about. I've been using Opera for a while now and have not noticed it having any JS issues.

Re:Opera

[whitehatlurker]

They may have fixed the problem - I did a run tonight on Opera 9.25 and no problems. I also ran the benchmark with Firefox 2.0.0.11. Not quite what I had expected, though. Firefox did much better than I had anticipated:

Opera: 68752.8ms +/- 9.2%
Firefox: 74978.8ms +/- 17.8%

"fasta" seems to be the weak point for Opera.

Bah humbug!

[SirJorgelOfBorgel]

What an absolutely horrible speed test.

First off IE6 is not tested, while it is still the most used browser. Also Opera 9.5 is not ready, it has so many bugs it just isn't funny anymore. Many sites break that worked fine in Opera 9.2.

But let's get to the good stuff. Yes in pure JavaScript like this, IE might be faster than Firefox. But in real world situations it clearly isn't. There is no test done on layout manipulation (and such) using JavaScript. Internet Explorer is notoriously horrible at this, especially if you use it combination with PNG's with alphachannel or complex CSS. Not to mention if you have to use JavaScript hacks because of IE6's lack of CSS support for the simplest things.

Funny is also how almost all JavaScript library speed tests I've seen put Internet Explorer far behind the others.

In 'real world' JavaScript performance Opera and Safari would be the winners, where I'd choose Safari as absolute winner, as Opera gains a lot of redrawing speed by cutting corners it should not cut which often result in display corruption (ie, the type that goes away when you force a redraw by minimizing and then maximizing the window again, or moving another window over Opera and then away again). Quite a bit behind in speed after Safari and Opera would be Firefox, followed even further back by Internet Explorer.

As a developer I still prefer Firefox for development though. Webkit is awesome, but the Safari GUI just plain sucks. Opera... hmm, I like it on my mobile devices, but it's just too weird for the desktop (what, textarea's don't even support scrolltop? wth!)

Re:Bah humbug!

[hedwards]

In 'real world' JavaScript performance Opera and Safari would be the winners, where I'd choose Safari as absolute winner, as Opera gains a lot of redrawing speed by cutting corners it should not cut which often result in display corruption (ie, the type that goes away when you force a redraw by minimizing and then maximizing the window again, or moving another window over Opera and then away again). Quite a bit behind in speed after Safari and Opera would be Firefox, followed even further back by Internet Explorer. I was wondering about that, a lot of the things that were listed as being a part of the benchmark aren't thing which I've ever used.

It looks to me like the benchmark was put together in a way that favors obscure optimizations over genuine real world use. 3d isn't something that I run into a whole lot on the web.
This looks less like performance issues and more like decisions made on the part of the developers as to what is more important than what.

Personally I'd be more focused on things like the regexes, string, controlflow, crypto and math. The other ones don't seem to be as important. The 3d especially is almost completely worthless, I can't recall the last time I encountered a page that actually required me to flip on javascript for that.

There also doesn't appear to be any particular correlation between how often these things are used. Date for example doesn't need to be messed with a whole lot, and except for calenders, there isn't really a burning reason why it needs to be used more than once per page. When it comes to access, I'm assuming that they are referring to the db, but it makes little sense to me to assume that the browsers will do similarly with different db systems.

Re:Bah humbug!

[Zott and Brock]

Instead of yet another JavaScript test I would like to see a comparison of rendering speeds for once. Opera 9.2 is absolutely horrible when it comes to scrolling speed, almost an order of magnitude slower than the rest. I wrote a page that autoscrolls in response to user input, with a little plane flying around the screen. It's unusable in Opera, but smoothly animated in every other browser I tried.

Re:Bah humbug!

[Phroggy]

First off IE6 is not tested, while it is still the most used browser. The WebKit team released a test suite, they didn't release test results. If you want to test IE6, then test IE6!

Yes in pure JavaScript like this, IE might be faster than Firefox. But in real world situations it clearly isn't. There is no test done on layout manipulation (and such) using JavaScript. Internet Explorer is notoriously horrible at this, especially if you use it combination with PNG's with alphachannel or complex CSS. This is intentional. This is specifically a JS speed test, not a DOM speed test. If IE's DOM handling is horribly slow, that's a different issue - not an unimportant one, but a different one. This test is really deigned for browser developers, not users, and that's important: while users don't usually care about specific implementation details and just want an overall faster experience, developers can only focus on specific implementation details. Thus, developers interested in improving JavaScript performance need to be able to look at JavaScript performance without being thrown off track by DOM problems, which are probably the responsibility of a completely different team of developers. JavaScript developers probably can't fix DOM problems, just as DOM developers can't fix JavaScript problems.

Re:Bah humbug!

[cheater512]

I've noticed that Konqueror is fantastic compared to Firefox at DOM manipulations.
Specifically drag drop stuff. Firefox stutters a little and Konqueror is very smooth.

Keep in mind that this is on a old P4 but still it highlights a difference.

Re:Bah humbug!

[cheater512]

The 3d stuff is for floating point math which is valid imho.

The only thing which wasnt tested is DOM. Presumably because the benchmark is for raw speed.
Everything else is used to varying extents. Go check off how many of them are used in something like GMail.

Re:Bah humbug!

[foniksonik]

Try out this site for some real javascript coolness... 99% of the site is html + javascript (they use prototype) although there are some flash based videos as well.... but flash is not used for any of the interface. okay, wait for it.....

GUCCI

even works in IE6... which is REALLY impressive

Re:Bah humbug!

[hkmwbz]

"Opera gains a lot of redrawing speed by cutting corners it should not cut"

Nonsense. Opera does not cut corners. The problems you are describing are normal bugs, not intentional, and do not make Opera faster (or slower). Please stop spreadig FUD about Opera just because it's much faster than Firefox.

Re:Bah humbug!

[buddyglass]

Funny is also how almost all JavaScript library speed tests I've seen put Internet Explorer far behind the others.

This hasn't been my experience. To test if I'm just misremembering, I googled up a few JS benchmarks and ran them on FF 2.0.11 and IE6 w/ latest patches, then Opera 9.25 and Safari 3 Beta for comparison. XP Pro 32-bit on a 2.4ghz P4 Northwood:

http://www.computerbytesman.com/js/jsbench/dobench.htm?
FF: 2078ms, IE: 1313ms, Opera: 875ms, Safari: NaN (some tests failed)

http://www.rahul.net/rhn/bench.js.html
primes: FF: 0.015s, IE: 0.016s, Opera: 0.015s, Safari: 0.015s
pgap: FF: 0.25s, IE: 0.125s, Opera: 0.110s, Safari: 0.140s
sieve: FF: 0.032s, IE: 0.031s, Opera: 0.031s, Safari: 0.062s
fib(20): FF: 0.015s, IE: 0.078s, Opera: 0.031s, Safari: 0.031s
tak: FF: 0.047s, IE: 0.234s, Opera: 0.078s, Safari: 0.141s
mb100: FF: 1.188s, IE: 0.344s, Opera: 0.235s, Safari: 0.500s

http://www.jorendorff.com/articles/javascript/speed-test.html
Pop: FF: 1.718s, IE: 56.3s, Opera: 1.544s, Safari: 0.891s
Parsing: with sloppy regular expression: FF: 10.232s, IE: 9.530s, Opera: 11.172s, Safari: 25.8s
Parsing: with sloppy hand-coded loop: FF: 82.100s, IE: 199.250s, Opera: 146.625s, Safari: 87.5s

For brevity I only listed the last two tests since they're by far the most time-consuming, plus the "Pop" test because IE did so exceptionally badly on it.

If anything, these results make me think it's a mixed bag and that all of the browsers could benefit from some targeted optimization. But I'm not sure it's really fair to say that FF blows away IE6 on every benchmark out there.

Some more data ...

[foobsr]

here

AMD Athlon 64 3200+, 1GB, Ubuntu 7.04, using FF for 4 hours, listening to last.fm.

CC.

Re:Some more data ...

[etymxris]

My results were a little better than yours, maybe 25%, but still about double the time of the firefox numbers in the article. Maybe it's the extensions I have, such as linkification. Dual Opteron 252, 6GB RAM, SuSE 10.3 64-bit, firefox 2.0.0.10.

Re:Some more data ...

[somersault]

That's very similar specs to the machine I have lying in my room in need of a new PSU. Apart from the fact that it isn't dual core, that machine is getting close to the limits of processor speed these days. I know you're just trolling, but for the last few years all non budget processors have been 'good enough' for desktop use. For gaming you just need to buy a better graphics card (okay, faster/multicore processors help with gaming too, but a 3200+ is nothing to sneeze at..)

Re:Some more data ...

[foobsr]

My results were a little better than yours, maybe 25%,

About what I get if I clean up and exclusively run the benchmark. But that is not a 'live' situation.

Anyway, this tells me that I do not need a new machine for what I do.

CC.

Re:Some more data ...

[mhall119]

I saw about a 30% speed improvement in FF3 over FF2 on my box. I also did not see any performance decrease in the "access" test like the author did, so maybe it was a fluke on his end. IE6 did moderately worse than FF2, just like in the article it did horribly in the "strings" test.

client side javascript will become our enemy

[icepick72]

Because of the incompatibilities and different bugs between browser JavaScript implementations for God's sake let's not have a world where client-side JavaScript is so fast we use it for everything. Development time will increase one more fold for each browser you want to support, and sometimes additionally for each minor version It will be hell on earth I predict.
My basic rule of thumb has also been that client scripting should enhance and application but not be required for the application. In other words with JavaScript disabled the application might act rudimentary but will still produce results.

Re:client side javascript will become our enemy

[gazbo]

Incompatibilities are disappearing at an alarming rate. Nowadays it's perfectly possible to develop a complex script on FF (appealing because of Firebug) and expect it to work with minimal if any modification on IE and Opera. Sure there are browser-specific functions, but they are almost invariably easy to avoid; the only real exceptions I can think of are different XML DOM methods, especially WRT namespaces.

Compare it to the days of IE5.5 vs Netscape 6 (the worst browser ever released) vs Netscape 4.7 and you can see what huge progress has been made.

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

Oh really? JavaScript is not that hard to get to work correctly cross browser. I spent a LOT more time changing CSS things to work nicely than I do on JavaScript and I do use a lot of JavaScript. If you use a decent JavaScript toolkit, like for example jQuery, it's even faster and you hardly have to worry about it at all. For any nice advanced stuff you simply have to use JavaScript, and that's what it's there for. You want to disable JavaScript? That's fine by me, but you WILL be missing out. Really, what's next, catering to people who don't have CSS? Sure there are a lot of people who think sites should still work and look readable without CSS, but really, that depends on the market segment of the website. You can't make rich websites without CSS and JavaScript. Simple. Not every site can get away with looking like Google.com, it depends on the target audience and the content.

Re:client side javascript will become our enemy

[truthsearch]

Nowadays it's perfectly possible to develop a complex script on FF (appealing because of Firebug) and expect it to work with minimal if any modification on IE and Opera.

I can second this statement. With libraries like prototype, and others that build on top of it, cross-browser development is simplified. The libraries take care of many of the differences between browsers, leaving the developer to work on the actual features.

Re:client side javascript will become our enemy

[Anonymous Coward]

"You want to disable JavaScript? That's fine by me, but you WILL be missing out."

Actually, _you_ will be missing out. Namely missing me as a member of your website's audience.

Re:client side javascript will become our enemy

[Anonymous Coward]

"you can see what huge progress has been made."

Yes, you can polish a turd to the n'th degree. But you must never forget that, as shiny as it may be, it is still a turd.

Re:client side javascript will become our enemy

[The13thSin]

I'm sure you will not be the target audience then! I'm pretty sure over 90% of the internet users have no idea how to disable javascript in their browser, so I guess you will not be missed as long as it's not a tech website.

Re:client side javascript will become our enemy

[icepick72]

You are the first in this thread to suggest disabling JavaScript. I'll have to respectfully disagree with disabling it. Like another poster said, most people don't know how to, also the users would be missing the enhancements of the JavaScript enabled web sites. Why should they be precluded from that? ... they shouldn't! Out of curiosity which browsers and versions do you actively target using jQuery. Where do these developments fit on a scale from full-fledged AJAX to simple DOM tweaks?

Re:client side javascript will become our enemy

[Marsell]

Considering how few people disable javascript, I don't think the people making websites will miss them. I doubt they're going to give up what they can achieve with javascript due to a very small minority.

I'm sure there's someone out there still using Mosaic. Should we throw out CSS too?

Re:client side javascript will become our enemy

[s4m7]

Really, what's next, catering to people who don't have CSS?

That's exactly why CSS exists... to separate content from layout/display characteristics. You can make an entirely graphical-button image-chopped page with all kinds of rollover goodness, and as long as you write your (x)html and CSS properly, it will break down fine in a text or mobile browser. Using techniques like image replacement is critical if you want your flashy website to be accessible to people using screen-readers or mobile browsers.

This of course assumes that your site has some kind of content, other than just pure uncategorized imagery.

Otherwise you could just put all your images in a table, put no alt attributes in and who cares? Oh, only the 40 million blind people in the world, and anyone who would want to use your site from a mobile device. Ahh, but those people probably aren't in your "target market" are they?

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

Well I'll assume with the JavaScript part you are referring to Anonymous Coward and the jQuery part you are referring to me.

For the project I am currently assigned to, I use jQuery for full-fledged AJAX, lots of client-side logic and a lot of DOM manipulation - pretty much as heavy as it gets with JavaScript, in short. I've also really used Dojo and gave Prototype, Mootools and ExtJS a short spin and prefer jQuery over any of them.

Note that even though I bash disabling JavaScript here, these projects I work on do actually support browsing without JavaScript for the public parts (ie those parts of the site you do not have to be registered for) so it still works with perfectly with Google and other search engines. Depending on the browser they will still look good or totally FUBAR'd, but the content is perfectly indexable by spiderbots.

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

You misunderstand me there. My stuff actually does work with screenreaders and such, but LOOKING at it with a CSS-less browser will not be pretty. But then again, if you are using a screenreader, I guess that doesn't really matter to you. But no, indeed, even if it didn't work, these people do not fit the target audience, as these sites I make are all in the visual art realm. As for mobile viewers, that's what we make mobile versions of the site for. I'm pretty much a mobile devices freak and I know what does and doesn't work. What doesn't work is trying to make a rich desktop web site work on a mobile device. The resolutions won't work, Pocket Internet Explorer is even worse than the normal Internet Explorer, even mobile Opera lacks some bits of essential javascript support (this however, is expected to be fixed in Opera Mobile 9 out soon, hurrah, that actually might work after all). As indicated before, it all really depends on the site. I'd type more but I have to go out to dinner. I do understand what you are getting at, and yes, we do care about and take care of these issues. The 'one site fits all' simply doesn't fly for this niche of sites though, I hope you understand that. And yes, that really has to do with the combination of main target audience and limitations of how HTML, CSS and JS work. As stated before, a site like Google can do that 'all in one', but for these sites, we can't.

Re:client side javascript will become our enemy

[Anonymous Coward]

"Should we throw out CSS too?"

Whatever tickles your testicles! However, I'll just have to say that I, like almost everyone else, do not go to websites to see clever JavaScript creations, demonstrations of AJAX eloquence, or the like: I go there to buy stuff and read things. And it appears that more than a few websites are quite usable with NoScript running. That you or others may be incapable of creating sites that have graceful fallback positions is, as I noted above, your problem, not mine.

Re:client side javascript will become our enemy

[s4m7]

What doesn't work is trying to make a rich desktop web site work on a mobile device. media="handheld" does wonders for this type of thing. I do appreciate what you're saying, but if the stuff you are doing is so non-standards-friendly, it's hard for me to understand why you wouldn't just do it in flash and forget the hassle.

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

While that may be true media="handheld" only works on the CSS part. Although I would say for just that most of our visuals just don't work at 320x240. A more important point however, is that mobile users have significantly less bandwidth to waste, so we want to strip out as much text content, images, desktop-IE specific code, etc from what is transmitted as possible. A few KB on a 'landline' makes very little difference (for these kinds of site, as they are graphics centered which already take a lot of bandwidth), but for mobile users you really try to slice off every last byte.

And what the hell, use Flash? From someone who is so adamant about standards as you are, that must be the most rediculous critique I have ever heard.

In the end what I'm saying is, it IS standards friendly to some extend, but it also has to look a lot more 'crispy' than your standard sites because the target audience just is that way. You wouldn't open a $500 dollar a meal restaurant in the tip of the eiffel tower and use bums as waiters, would you?

Re:client side javascript will become our enemy

[VGPowerlord]

Some sites also degrade gracefully to support people who disable Javascript. That doesn't mean you get as good a user experience as those who have it enabled, though.

Same test for OSX, please?

[stewbacca]

I'd like to see a similar test for OSX, maybe replacing IE with Camino (since I don't think IE will be made for OS X again?). Links, anyone?

Re:Same test for OSX, please?

[cbart387]

You are correct. It's been 4 years since Microsoft has developed IE for the Mac and two years since it was supported. ;). See here. Even though this is the case, a certain individual at my university will complain to our web team that a page doesn't work correctly with Mac IE.

Re:Same test for OSX, please?

[Anonymous Coward]

Here is Camino: http://webkit.org/perf/sunspider-0.9/sunspider-results.html?%7B%223d-cube%22:%5B326,325,321,322,323%5D,%223d-morph%22:%5B1212,1215,1203,1209,1194%5D,%223d-raytrace%22:%5B265,265,260,267,256%5D,%22access-binary-trees%22:%5B153,148,145,142,159%5D,%22access-fannkuch%22:%5B291,287,288,287,310%5D,%22access-nbody%22:%5B271,295,305,299,297%5D,%22access-nsieve%22:%5B214,218,213,213,216%5D,%22bitops-3bit-bits-in-byte%22:%5B278,267,266,266,270%5D,%22bitops-bits-in-byte%22:%5B266,263,262,264,264%5D,%22bitops-bitwise-and%22:%5B3546,3533,3550,3553,3509%5D,%22bitops-nsieve-bits%22:%5B205,207,201,203,201%5D,%22controlflow-recursive%22:%5B108,106,107,108,112%5D,%22crypto-aes%22:%5B218,220,215,217,218%5D,%22crypto-md5%22:%5B136,136,135,137,136%5D,%22crypto-sha1%22:%5B143,143,142,142,142%5D,%22date-format-tofte%22:%5B647,651,645,652,650%5D,%22date-format-xparb%22:%5B1230,1230,1229,1234,1244%5D,%22math-cordic%22:%5B304,300,300,300,302%5D,%22math-partial-sums%22:%5B342,344,336,324,343%5D,%22math-spectral-norm%22:%5B148,155,150,148,149%5D,%22regexp-dna%22:%5B561,557,560,555,560%5D,%22string-base64%22:%5B506,508,503,498,501%5D,%22string-fasta%22:%5B407,413,407,407,405%5D,%22string-tagcloud%22:%5B416,421,423,426,422%5D,%22string-unpack-code%22:%5B740,739,745,738,741%5D,%22string-validate-input%22:%5B203,200,202,202,200%5D%7D
Here is Safari:
http://webkit.org/perf/sunspider-0.9/sunspider-results.html?%7B%223d-cube%22:

Re:Same test for OSX, please?

[SimonTheSoundMan]

My own Camino using mtune=nocona and mssse3 flags:
Total: 7171.4ms +/- 0.4%

http://webkit.org/perf/sunspider-0.9/sunspider-results.html?%7B%223d-cube%22:%5B358,351,350,355,353%5D,%223d-morph%22:%5B573,574,574,567,575%5D,%223d-raytrace%22:%5B253,252,249,251,251%5D,%22access-binary-trees%22:%5B124,117,121,121,122%5D,%22access-fannkuch%22:%5B371,372,377,375,377%5D,%22access-nbody%22:%5B354,348,352,353,351%5D,%22access-nsieve%22:%5B162,160,168,158,157%5D,%22bitops-3bit-bits-in-byte%22:%5B160,157,158,156,155%5D,%22bitops-bits-in-byte%22:%5B168,168,167,166,169%5D,%22bitops-bitwise-and%22:%5B619,609,570,576,570%5D,%22bitops-nsieve-bits%22:%5B194,195,195,193,194%5D,%22controlflow-recursive%22:%5B80,77,79,74,75%5D,%22crypto-aes%22:%5B216,219,220,218,219%5D,%22crypto-md5%22:%5B115,115,115,112,117%5D,%22crypto-sha1%22:%5B127,127,126,129,126%5D,%22date-format-tofte%22:%5B355,364,362,360,361%5D,%22date-format-xparb%22:%5B212,213,209,210,206%5D,%22math-cordic%22:%5B339,331,336,342,341%5D,%22math-partial-sums%22:%5B313,293,301,310,313%5D,%22math-spectral-norm%22:%5B153,154,157,158,156%5D,%22regexp-dna%22:%5B357,368,364,363,364%5D,%22string-base64%22:%5B340,328,336,334,341%5D,%22string-fasta%22:%5B359,360,357,360,358%5D,%22string-tagcloud%22:%5B255,255,257,258,256%5D,%22string-unpack-code%22:%5B489,489,487,492,486%5D,%22string-validate-input%22:%5B165,171,173,167,168%5D%7D


Standard Camino 2.0alpha from today:
Total: 8211.6ms +/- 0.3%

http://webkit.org/perf/sunspider-0.9/sunspider-results.html?{%223d-cube%22:[449,423,421,438,425],%223d-morph%22:[707,700,693,696,691],%223d-raytrace%22:[302,298,298,284,296],%22access-binary-trees%22:[124,125,124,132,124],%22access-fannkuch%22:[425,425,425,423,425],%22access-nbody%22:[538,518,517,527,525],%22access-nsieve%22:[179,172,173,172,172],%22bitops-3bit-bits-in-byte%22:[183,180,184,183,181],%22bitops-bits-in-byte%22:[189,191,187,189,190],%22bitops-bitwise-and%22:[687,704,728,719,702],%22bitops-nsieve-bits%22:[226,221,224,223,222],%22controlflow-recursive%22:[91,92,93,98,93],%22crypto-aes%22:[230,229,229,226,225],%22crypto-md5%22:[144,122,138,143,141],%22crypto-sha1%22:[140,140,131,131,130],%22date-format-tofte%22:[396,408,395,396,398],%22date-format-xparb%22:[220,221,234,216,222],%22math-cordic%22:[377,375,375,376,376],%22math-partial-sums%22:[387,389,396,398,393],%22math-spectral-norm%22:[173,170,172,170,174],%22regexp-dna%22:[392,393,393,391,388],%22string-base64%22:[366,365,355,363,361],%22string-fasta%22:[379,377,397,375,378],%22string-tagcloud%22:[276,293,277,291,296],%22string-unpack-code%22:[472,469,503,474,466],%22string-validate-input%22:[164,196,162,198,196]}


Both on a MBP 2.4GHz stock.

Re:Same test for OSX, please?

[iMacGuy]

Your mbp 2.4 Core 2 is not a Nocona (try 'apple' or 'generic'), and SSSSSSSSSSSSSSSSSSSSSSSSSE3 probably doesn't affect generated code at all. (it might under gcc SVN where -ftree-vectorize is on by default, but I've only ever used it for dot products myself, which Camino isn't doing any of)

OF COURSE Firefox is slower!

[Anonymous Coward]

It takes time to change the setting in NoScript to allow JavaScript on the page in the first place.

I wouldn't give up that additional slowness for a 10,000% performance increase.

Jscript string concatenation sucks

[Anonymous Coward]

Aside from jscript lacklustre string handling, I've still never found it faster than spidermonkey. In some base64 tests I did, Opera fared really badly using an algorithm I found on their site -- while leading the pack with one I wrote myself. What I discovered was that given the right set of tests, any implementation can look favorable.

The unoptimized spidermonkey cli shell firmly trounced kjs last year when I did my testing, more likely what's being measured by these benchmarks is DOM access.

better idea

[ILuvRamen]

Why don't people just stop making ridiculously complicated pages? Have you seen the yahoo hompage? Aol's is even worse. And Ebay's is a ridiculous nightmare. I don't who thought that looked good or thought people will look at or read that much but they should be fired. No browsers in the world could render those pages in under a second the way they're supposed to look. Plus remember that like 99% of page load slowness is from ad servers failing to load the ads fast enough

Re:better idea

[francium de neobie]

You can have very complicated JavaScript logic running behind a seemingly non-complicated page.

lynx beats them all, 17 ms to pass test

[ls671]

I tried the same benchmark with my browser and it seems to beat them all, only 17 ms to pass the test !!!

~$ time lynx -dump http://webkit.org/perf/sunspider-0.9/sunspider-driver.html
SunSpider JavaScript Benchmark (In Progress...)

real 0m0.017s
user 0m0.001s
sys 0m0.004s
~$

Re:lynx beats them all, 17 ms to pass test

[ceoyoyo]

That's 17 ms to TAKE the test. I expect Opera 9.5, which the author says couldn't pass the test, also did quite well in test taking time.

Re:lynx beats them all, 17 ms to pass test

[oldhack]

That's a lie.

Firefox through Wine

[etymxris]

Bizarrely, Firefox for Windows running through wine runs faster than native Firefox. The wine installation doesn't have any add-ons though, so that might be the difference. Wine version is 0.9.51 and windows firefox version is 2.0.0.9, same machine as my post above.
Wine results. Native results.

Re:Firefox through Wine

[BZ]

It's not that bizarre... Wine is not an emulator (so no performance penalty of that sort), and MSVC++ produces better-optimized code than g++. It also produces about 40% smaller code, last I checked....

IE7

[falcon5768]

"If a probable anomaly in the IE7 results is overlooked" you mean like how IE7 goes backwards in Java implementation vs IE 6.

Now We'll See Performance Improve

[RAMMS EIN]

Good! Now that somebody has done a benchmark and it's been featured here, I expect some serious work will be done on JavaScript. I think performance will increase enormously in at least the developer-friendly browsers.

Not my experience

[Anonymous Coward]

I did a simple animation recently using javascript to move a couple of (DOM-)elements around the page it was jerky and ugly on IE (both 6 & 7), better in Konqueror and perfectly smooth in Firefox.
I suppose that's not a measure of performance as much as a measure of quality, but a few percent less cpu usage doesn't matter one bit if the result is ugly.

The JIT compiler isn't in JavaScript yet.

[Animats]

FireFox was supposed to be getting a JIT compiler for JavaScript. It's the one from the Flash player, where it runs ActionScript. That's apparently now expected in 2008. Then we'll see some real improvement.

Re:The JIT compiler isn't in JavaScript yet.

[bcrowell]

I test-drove Google Docs the other day, and the basic impression I got was, "What they're trying to do, you just can't do, because JS isn't fast enough." The word processor was reasonably usable on fast hardware, but the spreadsheet was just ridiculously slow. I wonder how this kind of thing will perform in Tamarin. It would be very cool if Firefox became the clear browser of choice for AJAX, and IE was left in the dust because MS wasn't agile enough to catch up :-)

Konqueror

[Fastball]

I have to confess that my favored browser, Konqueror, needs a swift kick in the ass when it comes to Javascript support. Too often I have to fire up Firefox in order to browse pages that have some measure of interaction, e.g. uploading images of things I'd like to sell on eBay. It's a shame, because otherwise, Konqueror is a wonderful, snappy browser. Here's hoping its devs whip it into shape sooner rather than later.

Re:Konqueror

[arodland]

Agreed.

I don't have access to the same hardware as Jeff, of course, but I do have both FF2 (2.0.0.8) and Konqueror (3.5.8). Konqueror took more than three times as long to run, on the same hardware. Konqueror 4rc2 was still slower than FF2, but almost exactly twice as fast as Konqueror 3.5.8... which is a pretty significant improvement, at least :)

Re:Konqueror

[mAriuZ]

i agree that konq 4 rc2 is little bit faster (and it feels a little bit speedier)
i had to kill -9 konq 3.x on these tests
also i have made some tests with webkit (gtk build) and it was faster than ffx2 and ffx3

It would be cool

[pembo13]

If no one makes excuses for Firefox's Javascript performance, especially if IE is faster than it... because I hate how IE handles DOM. Compared to the other browsers, which handle DOM okay, Firefox could do better however.

SSE Optimization

[Pearlswine]

I use a 3rd party build of Firefox, on my system I saw a ~25% speed increase in the test going from 12s on the standard firefox build to 9s on the third party build

Good one

[glwtta]

You know, it's cute to refer to "the big four" browsers, but you could've at least listed what you think those are - we are not mind readers.

Had it been "the big one and the one that just edged into relevance", then most people would know what you meant.

Re:Good one

[philwx]

You know, it's cute to refer to "the big four" browsers, but you could've at least listed what you think those are - we are not mind readers.

Had it been "the non-removable one pre-bundled with world's most popular OS, and the one that established a significant market share despite being completely optional", then most people would know what you meant.

FTFY

Re:Good one

[glwtta]

Yes, there shouldn't be a single sentence about Firefox that doesn't gush about how much of an underdog it is. Good thing you jumped in there.

It's just a web browser, get a grip.

And the winner: Linux

[tcdk]

Okay, maybe not, but this is my numbers:

WinXP Firefox 2.0.0.11: 18.8s
WinXP Internet Explorer 7.0.5730.11: 33.1s (same issue with the strings performance)
Ubuntu Firefox 2.0.0.6 (yeah, well): 15.3s

I only have opera running on my WinMobile Dell Axim v51x PDA and it's currently running, it seems to be 30-40 times slower than the desktop, so I'll not be waiting before I post...

Re:And the winner: Linux

[tcdk]

I only have opera running on my WinMobile Dell Axim v51x PDA and it's currently running, it seems to be 30-40 times slower than the desktop, so I'll not be waiting before I post...

Okay, it wasn't that bad - it finished in 317.8s. So 15-20 times slower. I was actually surpriced that it managed to run to the end.

It's Flash

[CrazedWalrus]

Firefox, for me, is really stable unless Flash is involved. Add Flash to the mix, and it goes down faster than a two dollar whore on a Friday night. By the way, so does Opera, but not quite as often. Close though. Just try watching 4-5 videos on YouTube.

I think Flash is the biggest DoS in the history of the web and Adobe really needs to take a good look at it. With all of these Flash ads and Flash-based video players, it really is a critical issue. Using adblock is an absolute must in my book, just to keep the browser running. My bet is some sort of resource leakage, since it happens over time -- like when watching several YouTube videos. It doesn't crash on the first or second one, but you're courting disaster on the third and above.

By the way, is there any way for FF to handle plugin crashes gracefully, i.e. *without* bringing down the browser with it? Maybe running it in a separate process somehow and just putting up a "broken image" sort of placeholder?

Re:It's Flash

[cheater512]

Seamonkey + Flash on my old P3 laptop is fine.

If by fine you mean freaking bloody slow.
Flash designers wouldnt know speed if it slapped them with a large trout.

YouTube is good. It can handle a video pretty well (occasional frame dropping).
Ads and many other things will reduce the computer to a crawl instantly.

Re:It's Flash

[willpall]

Yes, this is a reply to a sig. Mod me down

Re:It's Flash

[the_womble]

With all of these Flash ads and Flash-based video players, it really is a critical issue. Using adblock is an absolute must in my book

No, no, No! Wrong solution.

You are not giving websites any incentive to drop Flash ads.

Far better to use just Flashblock to block only Flash ads to text and plain image ads get more impressions. If all Adblock users switched to Flashblock websites would soon get the message. As it is, I expect to see more non-conventional formats (mostly annoying) like layer ads, intersitals etc.

Re:It's Flash

[pebs]

I haven't had Flash cause Firefox to crash. I can't even remember the last time Firefox crashed on me, in fact. And I use Firefox on Windows, OS X, and Linux regularly. I do, however, use the Flashblock extension, but have sites that require Flash unblocked, like YouTube. I do use Adblock as well, but only recently started using it. Maybe if I hadn't been using either of these extensions I'd have a problem, but haven't noticed any problems yet.

My problems with Firefox are all with the OS X version and some of its UI problems and bugs in certain extensions that only occur in the OS X version.

Compare JavaScript Frameworks

[Dekortage]

If you run the MooTools Slickspeed tests in different browsers, you find something interesting:

• jQuery is the fastest JavaScript framework in IE6 and 7, and the slowest in FireFox, and middle-of-the-pack in Safari.
• MooTools is the fastest in Firefox and Safari, and slowest in IE.
• Prototype is generally slower than the others, particularly in Safari, and frequently doesn't perform the tests correctly.

jQuery also claims to be the most accurate, though who knows for sure.

Re:Compare JavaScript Frameworks

[xutopia]

Funny I just ran this and found Prototype to be faster on Firefox. 197(prototype) 202(moo) 518 (jQuery)

Re:Compare JavaScript Frameworks

[Dekortage]

Weird. Maybe it's an OS thing -- I tested Firefox on Mac OS 10.4.11.

You also need to run it several times and average the scores. 197 versus 202 is basically the same score in these tests. 202 versus 518 is a more significant difference.

Just a note: it wasn't "supposed"

[ESqVIP]

AFAIK, Tamarin was since the beginning scheduled for Gecko 2 (i.e., Firefox 4). So, don't worry, it's not like it didn't make for Fx3, it wasn't supposed to be on this week's beta at all.

IE JScript string perf

[browneye]

Posted in the comments to TFA:

There was an article about IE's string performance in the Jscript team blog on MSDN a while back : http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx
Aaargh! on December 20, 2007 11:34 AM

Firefox 2 vs IE

[owlstead]

Seems to me that the more important ones are all for firefox. FF beats IE on access, control flow, crypto and strings. IE beats FF on 3D, bitops, date and regexp. They are about even on math.

Now bitops could be important for a browser, but I would not see too many pages doing things with 3D. Date and regexp are important, but they are hardly things you do in a loop on a regular basis. Access, control flow, crypto and strings seem more important to me.

Just adding up the benchmark results was pretty weird imho. Just putting them in 9 separate screens would be better, especially if the author had the decency to at least look up the contents of the tests. Ah well, presentation over content I suppose.

What I learned.

[Vexorian]

Once you need a benchmark to prove something is faster than something else, then it doesn't really matter which one you uses.

Slowdown due to add-ons

[AmiMoJo]

It seems strange that add-ons for Firefox should slow down Javascript execution times. I did a test to confirm it, but it's apparently the case. My guess is that it's because add-ons which execute as pages are loaded mess with the benchmark. My FF was 2x slower with add-ons.

The actual problem...

[encoderer]

The actual problem is the way JScript does string concatenation.

When you concatenate 2 strings in JScript, it determines the size of the buffer needed, allocates the buffer, does the concatenation, and returns the result to the caller.

Which works fine, until you start putting some load on those old tires...

x = 'some';
y = 'string';
z = 'here';

testString = x + " " + y + " " + z;

(Ignore that nobody would actually write code JUST LIKE THAT, they would just add a trailing or leading space to the x, y & z strings. But concatenating a result with some white space is not abnormal.)

Now, just think about what this is actually doing under the hood..

1. determine len of x (4) plus len of " " (1) = 5
2. Allocate new buffer(5)
3. Concatenate, assign result to temp
4. determine len of temp (5) plus len of y (6) = 11
5. Allocate new buffer(11)
6. Concatenate, assign results to new temp, destroy old temp
7. determine len of temp (11) plus len of " " (1) = 12
6. Allocate new buffer(12)
8. Concatenate, assign results to new temp, destroy old temp
9. determine len of temp (12) plus len of z (4) = 16
10. Allocate new buffer (16)
11. Concatenate, assign results to testString

So, to concatenate relatively little string data, 3 temporary buffers were needed and 4 separate allocations were done.

It works fine, right up to the point where it doesn't :)

Re:The actual problem...

[encoderer]

1
2
...
6
7
6
8
...
11

In other news, somebody has appeared to do some overloading on my internal increment-operator :)

Re:The actual problem...

[smittyoneeach]

Of course there is the old standby remark about how choice of licensing reduces us to mere speculation, instead of real knowledge.

Re:The actual problem...

[x0n]

why did you just paste the source URL?

http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx ...would have saved you some copy and pasting.

Re:The actual problem...

[encoderer]

I read that about 2 months ago when it was written.

It was just as easy to explain it as it would've been to search for the blog entry.

Thanks for digging it up.

Re:The actual problem...

[jsoderba]

The link was in TFA.

still, pretty fast

[roman_mir]

this script

for (;;) {}

was shown to be the slowest executing script in FF, IE ran the loop in under 2 seconds.

IE7 is faster with strings in my experience

[Eric Coleman]

For compressing roughly a 100K js, IE7 is far faster than Firefox. I've seen firefox take over an hour to compress js with interruptions that "this script is running too slow", while IE takes only a few minutes. Opera corrupts large scripts, so it's useless in this context. I haven't tested Safari for compressing javascript.

However, for real 3D, IE7 is really really really slow. Firefox is OK, Safari on windows is the fastest. http://www.abrahamjoffe.com.au/ben/canvascape/textures.htm

We would?

[Anonymous Coward]

> Had it been "the big one and the one that just edged into relevance", then most people would know what you meant.

IE6 & IE7?

Opera 9.50b crashes on WebKit's test

[hotfireball]

I've found unable to test Opera 9.5b on WebKit's SunRise test. Thus I've tested using this one: http://www.jorendorff.com/articles/javascript/speed-test.html and it appears that standard Safari from Leopard (version 3.0.4, build 5523.10.6) in some places same as Opera 9.50b, in some places bit faster and in some places as twice as faster than Opera. Also, Opera fails lots of tests with traceback errors.

Check it out yourself.

Re:Opera 9.50b crashes on WebKit's test

[whitehatlurker]

Use Opera 9.25 and the page works without error. I'm not interested enough to retry with another browser, especially not a beta - either Opera or Firefox. Caveat - done from Windows.

Speedup due to add-ons

[Jaxoreth]

My FF was 2x slower with add-ons.

Strange... mine is actually faster with add-ons. Then again, my add-ons are AdBlock Plus and NoScript.

Re:Speedup due to add-ons

[AmiMoJo]

I use Adblock+ and generally it does make things faster. I was talking about Javascript performance. With NoScript enabled you could not run the benchmark.

Vista + IE 7 vs Ubuntu 7.10 + FF 2

[michaelwigle]

I did the test on a dual-boot Intel Core 2 Duo 2.0 GHz with 2 GB RAM Comparing Vista and IE 7 with Ubuntu 7.10 and FireFox 2. Vista took 17461.6ms and Ubuntu took 12532.4ms for a 15% improvement.

Here are the links to the full reports:

Windows Results and Ubuntu Results