Firefox to get massive JavaScript performance boost

http://arstechnica.com/news.ars/post/20080822-firefox-to-get-massive-javascript-performance-boost.html

by apu • 18 years ago

53 26 18 years ago

truebosko• 18 years ago

This is great news. I thought the boosts in JS for Firefox 3 were nice, this looks even better!

gruseom4• 18 years ago

For a lot of web apps, including the one I'm working on, the JS interpreter isn't the bottleneck, or even close. Basically, anything involving rendering or the DOM is orders of magnitude slower than pure JS computation. So what's the point of optimizing function call and loop overhead? For what real-world apps will this make a noticeable difference?

When we ran our app in FF3 for the first time, we were dismayed to find that, after all the talk about browser performance improvements, it had actually gotten a lot slower (especially when scrolling) [~]. As far as I can tell, they're optimizing the wrong stuff. It's possible that our app is unique, but I doubt it. To judge by Google, many people appear to be experiencing the same thing.

[~] Safari 3, on the other hand, sped up our app considerably.

Edit: The only person I know of who's raised this issue is John Resig: http://ejohn.org/blog/javascript-performance-stack/

ComputerGuru• 18 years ago

Thanks for bringing this to the light.

I'm sorry to say that Firefox has become more about the marketing and less about the code - they're too worried about looking good in the benchmarks and raising their mass-market appeal than about true good code and user experience.

From JS benchmarks to SSL certificates (http://royal.pingdom.com/?p=339) to false advertising of FF3's memory consumption (http://neosmart.net/blog/2008/firefox-3-is-still-a-memory-ho...) - it's all going downhill.

thorax• 18 years ago

I have my beefs with Mozilla, but to say they aren't focusing on code is crazy. The stuff they're doing (especially with the native JS compilation) is very difficult stuff that honestly has a chance to change all browsers for good.

I have good friends on their *Monkey teams and can say without a doubt that there's a lot of impressive code going in there. Stuff that someone absolutely needs to be doing-- and it's all available for free.

I agree I'm also annoyed with FF memory consumption and some stability issues I've had lately, but I can't disagree more firmly on the quality of the code they have. Without much research, you can find code at Mozilla that's better than what major for-profit companies are producing out of their R&D-- and it works across a dozen platforms.

sayrer• 18 years ago

what's your app?

gruseom4• 18 years ago

It's a kind of spreadsheet.

Edit: I realized my reference to Resig might be misleading. It's a post from Feb 2008 about browser optimization in general, not FF3. The point is that he talks about how browser optimization has to include rendering and DOM operations.

jacobolus• 18 years ago

> … what's the point of optimizing function call and loop overhead? For what real-world apps will this make a noticeable difference?

It will make a difference in real-world apps which are currently impossible because they would perform poorly. It will become reasonable to start putting real number-crunching into browser-side JavaScript code—things like crypto, physics calculations, etc. As one example, JavaScript games are going to get a whole lot better in the next couple of years.

(Not to say that they shouldn’t be optimizing DOM access, or scrolling speed, or whatever.)

gruseom4• 18 years ago

What you're saying is reasonable - for apps that don't need much UI. I wonder, though, how many real-world examples there are of apps that people have tried and failed to write in Javascript for this reason.

For those of us working on things where the UI requirements are more intensive, little progress has been made. Perhaps the pure JS stuff is getting more effort because it's more glamorous?

michaelneale3• 18 years ago

Yeah whilst this does mean some computation expensive things can be pushed to the client more (without plugins) - I think you are right. Most real world disappointment with browser rendering performance is DOM related. Eg large grids in data intensive applications.

whalliburton• 18 years ago

This is not my experience. Moving from FF2 to FF3 I saw noticeable improvements in the application responsiveness, especially in moving DOM objects around the window (ala draggable dialog boxes full of objects), mouse event handling, and in generation of new DOM children. While at the same time FF3 was using less memory.

andreyf• 18 years ago

You realize that John Resig works for Mozilla and probably has at least a little input in what FF is optimizes.

gruseom4• 18 years ago

I hope so. But that hardly follows from the fact that he works there.

ars3• 18 years ago

This is nice, but the only upgrade firefox actually needs is multithreading and they won't do it (according to some blog I read, which I couldn't re-find).

They can optimize all they want, and it'll help, but Intel hit a wall with CPU performance, and multi-core is the future.

jsrn• 18 years ago

> according to some blog I read, which I couldn't re-find

I think this is the blog post by Brendan Eich you are referring to:

   So my default answer to questions such as the one I got
   at last May's Ajax Experience, "When will you add
   threads to JavaScript?" is: "over your dead body!"

   There are better ways. Clueful hackers keep rediscovering
   Erlang. Then there is STM. One retro stylist I know
   points to an old language-based solution, Hermes.

   A requirement for JS3 (along with hygienic macros) is
   to do something along these more implicit lines of
   concurrency support. In all the fast yet maintainable
   MT systems I've built or worked on, the key idea (which
   Will Clinger stated clearly to me over lunch last fall)
   is to separate the mutable unshared data from the
   immutable shared data. Do that well, with language and
   VM support, and threads become what they should be:
   not an abstraction violator from hell, but a scaling
   device that can be composed with existing abstractions.

   So here's a promise about threads, one that I will
   keep or else buy someone a trip to New Zealand and
   Australia (or should I say, a trip here for those over
   there): JS3 will be ready for the multicore desktop
   workload.

http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre...

in essence, he plans to take advantage of multicore processors not with threads but with better and/or more programmer friendly methods.

ars3• 18 years ago

Yah, that's the one. And we'll see if he delivers, but I know one thing right now: when I sit and wait while one very slow site freezes the whole browser, I get quite annoyed.

Does he not realize that the browser is basically the OS these days, and he's keeping it in Windows 3.0 territory?

It's time to make a thread for the UI, and a thread for each window, and each tab (child windows AKA popups, shall thread with their parent). JS can't cross those walls anyway, so his probably with concurrency are not as bad as he thinks.

invisible• 18 years ago

This is a huge achievement for the future of the web. While the basics of what we're doing now are very simple, the ability to have code be compiled on the fly is exactly is needed to get JavaScript near pre-compiled code boundaries. I do yearn for a world where our biggest successes are much bigger than forums that graduated into social sites.

As gruseom stated, interacting with the DOM and rendering as still significantly slower than iterating through an array. I believe tracing very well could be the key to unlocking advances in that area s well.

rplevy• 18 years ago

(push 'javascript dynamic-languages-faster-than-C)

tlrobinson• 18 years ago

While I consider myself a WebKit man, it's good to see Firefox competing, The competition benefits everyone.

Unfortunately, IE is still quite slow. I think we'll soon reach the point where it's not the browser feature inconsistencies limiting what cross-browser JS apps can do, but the performance difference.

michaelneale3• 18 years ago

I think its already here for the bleeding edge. I have seen some (small) apps where they give up on IE purely for performance reasons (their users are happy for that compromise) - buts its ONLY for performance reasons.

Firefox to get massive JavaScript performance boost

Related Stories