I’m using JavaScript to do client-side manipulation of large tables (filtering, sorting, and hiding columns). Performance is good up to maybe 100 rows with 20 columns, and it’s usable up to a few hundred rows, but it really bogs down beyond that. This is an internal application, so I can’t actually post a link to it.
Some of the reports are as many as 9000 (9 thousand) rows, at which point things really bog down badly (we’re talking minutes for sorting here). The actual sort still takes less than half the total time required to sort on a column; the rest of it is mostly related to actually reordering the rows in the DOM and rendering the result.
Filtering isn’t as bad, but all the string manipulations (I’m using Firefox on either a 2.2 GHz P4 running Linux or a 1.8 GHz UltraSPARC-IV+ running Solaris; the difference in performance isn’t going to affect the usability to any great degree) still add up.
The reason for this client-side data manipulation is to allow users to generate customized reports.
As the main author of the SunSpider benchmark, I don’t think it makes sense to discount IE’s results on the string tests. As far as I can tell, what the string tests do is sane and realistic, and they are showing a genuine performance problem in IE, in types of code that are pretty common on the web. As you can see in the detailed results, more than one of the string tests does much worse than other browsers.
After reading various complaints about the Opera browser, I have to insist that I have very few issues running Opera today. This includes all contemporary websites such as: Gmail, Goog. Reader, Digg, Hotmail, Y!Mail, etc. NO ISSUES and no complaints. The price of greatness is the occasional stumble. I have been using Opera as my main browser since 6.x, and it has improved in compatibility across the web ever so much. Granted, there are times Firefox is necessary - if something doesn’t appear right in the O, use FF. and if all else fails, try IE.
Additionally, I successfully ran the sunspider test on Opera (v9.24) in Linux without getting the NaN errors Jeff mentioned. [ result is 10.7 s ] (Macbook Pro 3rdGen SR 2.2C2D, 2GB, Ubunutu 7.10)
And I agree with some other posters: the second graph is pretty but remarkably bad, making it very easy to compare the runtime of different benchmarks (apples and oranges–useless!) as totaled across the browsers (double useless!) and very difficult to compare the browsers to each other.
Disagree.
The top graph and bottom graph are mirrors. So if you don’t like the bottom graph, look at the top one.
It is useful to know what general class of activities in JavaScript are slow, and that’s what the bottom graph shows – string operations and bitwise operations tend to be the slowest activities in JavaScript. Just scan the relative colors to see which browser was good (or bad) at a particular class of operations in JavaScript.
Also, please do NOT post ultra-long URLs in the comments. I’ll be removing those. If you want to post your results, use TinyURL or another shortening service.
I will never understand why Firefox doesn’t offer a 64-bit
version. I’m sure it’d be even speedier!
This is a Windows x64 Firefox build for XP. Some run it on Vista too. Perhaps you could give it a try. Official Mozilla Windows x64 support will arive with Firefox 3.0 as there apparently is a customer requirement for this.
As mentioned above, the “anomalous” result of IE is not that anomalous. In some testing we have done on JS performance, IE6 and IE7 are both perform horribly when handling strings over a non-trivial size. And, while that is avoidable in some cases, the fact is the string data type gets quite a bit of use.
Really, is “anomalous” really the right word to describe IE’s poor string performance? It appears to be an acknowledged bug that’s not fixed yet, not a mistake in the test. I’d have called it lackluster, personally.
That said, I have heard of people working around it by shoving all their strings into an array and joining them all at the same time, but that’s quite a pain when you have to go to such lengths just for one browser. Of course, IE has always been like that to develop for…
The browser market is more competitive than it has been in years, with Opera 9.5, Firefox 3, Safari 3, and IE 8 all vying for the coveted default browser position.
All this competitiveness just means juggling with lots of incompatibilities; a href="http://www.quirksmode.org/dom/w3c_html.html"http://www.quirksmode.org/dom/w3c_html.html/a and more. While an XMLHttpRequest is rather universal (and even that took long enough), placement and rendering of elements isn’t, and most mobile browsers (which support a half-assed featureset) make this even worse, because you have to scale back your design to 1998.
We’ll have to deal with the spectre of IE6 for a few more years, I’m afraid.
once you factor out that wildly anomalous string result.
I doubt it’s anomalous. In fact, I think it’s a direct consequence of MSIE’s awful garbage collector and garbage collection scheme. I haven’t looked at the tests but string probably generates a lot of junk objects and MSIE’s behaviour degrades extremely badly once you reach a precise threshold (in number of objects in memory I think) although I don’t remember that threshold right now.
All this competitiveness just means juggling with lots of incompatibilities
Since 95% of the incompatibilities come from MSIE and limit the JS programmer to a restricted set of features which are usually well supported cross-browser by everybody else, that usually isn’t much of a problem (and I’m serious there, especially since Safari 3. Safari 2’s JS support sucked balls but Safari 3’s is very good)
Have they improved the font rendering in the newer safaris? I am currently running it on xp because it’s font rendering is so much better than msie or firefox. (maybe it has to do with screensize/resolution? It looks really great on 15inch 1920x1200)
Jeff: FF is usually distributed 32-bit, even on 64-bit OSes, due to Flash and other plugins only being distributed 32-bit. FF works very well when build 64-bit.
