5 ms·

Firefox to get massive JavaScript performance boost

53 points by apu 18y ago

truebosko 18y ago
This is great news. I thought the boosts in JS for Firefox 3 were nice, this looks even better!
gruseom 18y 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/ http://ejohn.org/blog/javascript-performance-stack/
- ComputerGuru 18y 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 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-hog/ http://neosmart.net/blog/2008/firefox-3-is-still-a-memory-ho...) - it's all going downhill.
  - thorax 18y 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.
    - unalone 18y ago
      I think he was using words loosely - I have the same problem. Namely, this isn't nerds working on something awesome anymore. It's marketing. Old Firefox wouldn't have done something stupid like break a world record: it didn't need to. It was all about finding a browser that you liked and using it. Then the fucking browser wars started, and all of us fucked away hours on it, and Firefox/Google took notice and started playing the game, which was a shit move. So the coding is still good, no doubt, but Firefox has become a movement rather than a piece of software.
      - agotterer 18y ago
        Is there anything wrong with marketing? Sure on one hand you could say they "sold out". But underneath all the open source and hackers they are a company... a for profit company at that. They are pushing a product that is superior to the current standard and are forcing inovation that might have taken significantly longer had they not become a serious threat. So if a few tactics like setting world records helps spread the word and make the internet better, I'm all for it. I would love to see Firefox become the industry standard. It will force other browsers to start playing by the rules, mainly living up to standards and working harder to make a better product. Competition is what creates better products. When you have a monopoly or are the only major player in an industry you aren't as innovative. You don't need to be. Look at the cell phone market pre iPhone... now everything is touch screen and has internet...
- sayrer 18y ago
  what's your app?
  - gruseom 18y 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 18y 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.)
  - gruseom 18y 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?
    - michaelneale 18y ago
      >Perhaps the pure JS stuff is getting more effort because it's more glamorous? funny you mention that, but I think a lot of things are driving by glamour or fashion. Although in this case its clearly an engineering achievement, so kudos, and its great to have 2 competing and excellent open source browsers. But still... glamour...
- michaelneale 18y 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 18y 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 18y ago
  You realize that John Resig works for Mozilla and probably has at least a little input in what FF is optimizes.
  - gruseom 18y ago
    I hope so. But that hardly follows from the fact that he works there.
ars 18y 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 18y 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/threads_suck.html 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.
  - ars 18y 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 18y 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 18y ago
(push 'javascript dynamic-languages-faster-than-C)
tlrobinson 18y 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.
- michaelneale 18y 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.

53 points by apu 18y ago

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

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/ http://ejohn.org/blog/javascript-performance-stack/

ComputerGuru 18y 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 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-hog/ http://neosmart.net/blog/2008/firefox-3-is-still-a-memory-ho...) - it's all going downhill.
- thorax 18y 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.
  - unalone 18y ago
    I think he was using words loosely - I have the same problem. Namely, this isn't nerds working on something awesome anymore. It's marketing. Old Firefox wouldn't have done something stupid like break a world record: it didn't need to. It was all about finding a browser that you liked and using it. Then the fucking browser wars started, and all of us fucked away hours on it, and Firefox/Google took notice and started playing the game, which was a shit move. So the coding is still good, no doubt, but Firefox has become a movement rather than a piece of software.
    - agotterer 18y ago
      Is there anything wrong with marketing? Sure on one hand you could say they "sold out". But underneath all the open source and hackers they are a company... a for profit company at that. They are pushing a product that is superior to the current standard and are forcing inovation that might have taken significantly longer had they not become a serious threat. So if a few tactics like setting world records helps spread the word and make the internet better, I'm all for it. I would love to see Firefox become the industry standard. It will force other browsers to start playing by the rules, mainly living up to standards and working harder to make a better product. Competition is what creates better products. When you have a monopoly or are the only major player in an industry you aren't as innovative. You don't need to be. Look at the cell phone market pre iPhone... now everything is touch screen and has internet...
sayrer 18y ago
what's your app?
- gruseom 18y 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 18y 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.)
- gruseom 18y 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?
  - michaelneale 18y ago
    >Perhaps the pure JS stuff is getting more effort because it's more glamorous? funny you mention that, but I think a lot of things are driving by glamour or fashion. Although in this case its clearly an engineering achievement, so kudos, and its great to have 2 competing and excellent open source browsers. But still... glamour...
michaelneale 18y 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 18y 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 18y ago
You realize that John Resig works for Mozilla and probably has at least a little input in what FF is optimizes.
- gruseom 18y ago
  I hope so. But that hardly follows from the fact that he works there.

ars 18y 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 18y 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/threads_suck.html 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.
- ars 18y 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 18y 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 18y ago

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

tlrobinson 18y 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.

michaelneale 18y 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.