5 ms·

The benchmark at the bottom showing how far behind Firefox has fallen on JS performance is pretty telling. It confirms my own recent observation that Firefox is

The benchmark at the bottom showing how far behind Firefox has fallen on JS performance is pretty telling. It confirms my own recent observation that Firefox is at least 3-6 times slower in practice for the particular app I'm working on.

om2 9y ago
This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).
- rhizome 9y ago
  And that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.
  - draw_down 9y ago
    Oh wow, that's pretty terrible.
  - kevin_thibedeau 9y ago
    That's more of an indication that Chrome monoculture encourages crap developer practices. There's no reason a messaging site should be so bloated that it brings a modern browser to it's knees.
  - emmelaich 9y ago
    Are you sure that's mere slowness? I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
  - floatboth 9y ago
    re "all Firefox tabs and window instances are frozen" — looks like you don't have multiprocess enabled. Check about:support for Multiprocess windows and Asynchronous Pan/Zoom.
  - acjohnson55 9y ago
    That's weird. Firefox is my first-choice browser, and it only takes a couple seconds to load Twitter. You might want to see if you have any badly behaving plugins.
- boubiyeah 9y ago
  It's important to note, yes. Maybe Firefox is just a bit lagging in its optimization schedule. Also, all deployed sites and apps today are actually running ES5 transpiled from ES6.
kevingadd 9y ago
A vendor is always the fastest when they roll out a new benchmark. It's disingenuous to suggest a browser is '3-6x slower' based on a score on one benchmark, when all the vendors actively compete on and optimize against a large set of benchmarks, and compare each others' performance numbers on individual tests to understand engine weaknesses/strengths. fwiw, Chrome, Firefox and Safari have all been fairly competitive on the major performance benchmark (Octane) for a while, with jsc taking a bit to catch up to the others. Sunspider and Kraken are now relatively outdated because everyone is fast on them: https://arewefastyet.com/ https://arewefastyet.com/ Octane is on the way out, so I have no doubt that the vendors will all pull close together on this new Apple benchmark set once they have time to optimize for it, since most of these benchmarks are cynical gaming anyway more than they are real applications. (Octane, which is culled from real webapps, had a glaring bug in one of its test cases for a while that happened to make v8 much faster at the cost of the test not actually doing real work.) It's also silly to judge a browser's performance based on how fast bleeding-edge features are. Bleeding-edge features can't be fully/effectively optimized until there are real-world examples of how they are used. P.S. it may be interesting to look at https://arewefastyet.com/#machine=36 https://arewefastyet.com/#machine=36 and note that the JS runtime in MS's Edge is shockingly competitive on these benchmarks as well. You can't count anyone out of the race.
- Androider 9y ago
  The performance difference I see with my own app with Firefox is exactly the benchmark's 3-6x, that's not a benchmark but real world usage. It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, making Firefox unusable for development, while Chrome works just fine.
  - kevingadd 9y ago
    If your app is 3-6x slower overall in Firefox to the point of animations & dragging being slower, and to the point that non-minification makes it slower... something is wrong with your app. Animations are generally the work of the layout engine and compositor, which is absolutely not going to be impacted by jsc's latest JS optimizations, or by ES6 features. For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong. Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application. If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).
franciscop 9y ago
Well, that should be pretty non-surprising. There are 4 mayor Javascript engines and 3 of them belong to some of the largest companies in the world (Apple, Alphabet and Microsoft). It was just a matter of time before they caught up through throwing money at the problem. I use Firefox (except for Hangouts) but I understand Chrome's advantaged situation will probably allow them to be the sole competitor in the near-middle future.
- jonas21 9y ago
  On the other hand, it's not like Firefox is the side project of a few of people in their spare time -- the Mozilla Foundation has annual revenue of over $400 million! [1] https://en.wikipedia.org/wiki/Mozilla_Foundation https://en.wikipedia.org/wiki/Mozilla_Foundation
  - franciscop 9y ago
    I do not have an inside look, but if I remember correctly there were few calls about Mozilla losing focus on Firefox through making Firefox OS for a few years, which is exactly when the other vendors were reinventing their engines. They made some great work with Rust though (;
    - fabrice_d 9y ago
      Firefox OS led Mozilla to push a lot on the performance front in Gecko, mostly in gfx land. The JS perf is mostly SpiderMonkey and there was very little FxOS specific work done (as far as I remember, we mostly got help to tune the GC heuristics) because the JS team was already streched pretty thin. These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/# https://arewefastyet.com/#). The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.
  - chc 9y ago
    $400 million looks like a lot until you remember that Apple have $267 billion in cash reserves. The Mozilla Foundation's entire annual revenue isn't even a fifth of a percent of what Apple have just sitting around because they can't find a better use for it. The fact that Mozilla are able to punch even this far above their weight is kind of impressive.
bzbarsky 9y ago
Mostly what the benchmark shows is that the benchmark in question measures one specific thing which doesn't have a JIT fast path in Firefox yet, but measures it multiple times in different ways... [Edit: Actually two things: hot loops in the same function as a class definition, and derived classes that use "super".] Chances are whatever you see on your app is a different issue. I'd be happy to profile and file bugs as needed if you can get me a link that shows the problem on your app.
- jfbastien 9y ago
  Interesting. What is that thing exactly? Is there a bug we can follow?
  - bzbarsky 9y ago
    Actually, I guess there are two things: 1) If you have a class definition inside a function, that function doesn't get jitted. The functions in the class definition itself can still get jitted. 2) Class methods that use super don't get jitted at the moment. So if your class definitions are not in the same function as your hot code and don't use super, you get fast paths. Otherwise some things will run in the interpreter. The tracking bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 and https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 is what the above summary is based on.
omnimus 9y ago
It strange i dont know in which world i am living but i always have opposite feeling. I use lot of tabs and well chrome might start faster but if you have 30 tabs open it slows my whole computer. With firefox it seems all fine.

om2 9y ago

This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).

rhizome 9y ago
And that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.
- draw_down 9y ago
  Oh wow, that's pretty terrible.
- kevin_thibedeau 9y ago
  That's more of an indication that Chrome monoculture encourages crap developer practices. There's no reason a messaging site should be so bloated that it brings a modern browser to it's knees.
- emmelaich 9y ago
  Are you sure that's mere slowness? I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
- floatboth 9y ago
  re "all Firefox tabs and window instances are frozen" — looks like you don't have multiprocess enabled. Check about:support for Multiprocess windows and Asynchronous Pan/Zoom.
- acjohnson55 9y ago
  That's weird. Firefox is my first-choice browser, and it only takes a couple seconds to load Twitter. You might want to see if you have any badly behaving plugins.
boubiyeah 9y ago
It's important to note, yes. Maybe Firefox is just a bit lagging in its optimization schedule. Also, all deployed sites and apps today are actually running ES5 transpiled from ES6.

kevingadd 9y ago

A vendor is always the fastest when they roll out a new benchmark. It's disingenuous to suggest a browser is '3-6x slower' based on a score on one benchmark, when all the vendors actively compete on and optimize against a large set of benchmarks, and compare each others' performance numbers on individual tests to understand engine weaknesses/strengths. fwiw, Chrome, Firefox and Safari have all been fairly competitive on the major performance benchmark (Octane) for a while, with jsc taking a bit to catch up to the others. Sunspider and Kraken are now relatively outdated because everyone is fast on them: https://arewefastyet.com/ https://arewefastyet.com/ Octane is on the way out, so I have no doubt that the vendors will all pull close together on this new Apple benchmark set once they have time to optimize for it, since most of these benchmarks are cynical gaming anyway more than they are real applications. (Octane, which is culled from real webapps, had a glaring bug in one of its test cases for a while that happened to make v8 much faster at the cost of the test not actually doing real work.) It's also silly to judge a browser's performance based on how fast bleeding-edge features are. Bleeding-edge features can't be fully/effectively optimized until there are real-world examples of how they are used. P.S. it may be interesting to look at https://arewefastyet.com/#machine=36 https://arewefastyet.com/#machine=36 and note that the JS runtime in MS's Edge is shockingly competitive on these benchmarks as well. You can't count anyone out of the race.

Androider 9y ago
The performance difference I see with my own app with Firefox is exactly the benchmark's 3-6x, that's not a benchmark but real world usage. It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, making Firefox unusable for development, while Chrome works just fine.
- kevingadd 9y ago
  If your app is 3-6x slower overall in Firefox to the point of animations & dragging being slower, and to the point that non-minification makes it slower... something is wrong with your app. Animations are generally the work of the layout engine and compositor, which is absolutely not going to be impacted by jsc's latest JS optimizations, or by ES6 features. For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong. Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application. If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).

franciscop 9y ago

Well, that should be pretty non-surprising. There are 4 mayor Javascript engines and 3 of them belong to some of the largest companies in the world (Apple, Alphabet and Microsoft). It was just a matter of time before they caught up through throwing money at the problem. I use Firefox (except for Hangouts) but I understand Chrome's advantaged situation will probably allow them to be the sole competitor in the near-middle future.

jonas21 9y ago
On the other hand, it's not like Firefox is the side project of a few of people in their spare time -- the Mozilla Foundation has annual revenue of over $400 million! [1] https://en.wikipedia.org/wiki/Mozilla_Foundation https://en.wikipedia.org/wiki/Mozilla_Foundation
- franciscop 9y ago
  I do not have an inside look, but if I remember correctly there were few calls about Mozilla losing focus on Firefox through making Firefox OS for a few years, which is exactly when the other vendors were reinventing their engines. They made some great work with Rust though (;
  - fabrice_d 9y ago
    Firefox OS led Mozilla to push a lot on the performance front in Gecko, mostly in gfx land. The JS perf is mostly SpiderMonkey and there was very little FxOS specific work done (as far as I remember, we mostly got help to tune the GC heuristics) because the JS team was already streched pretty thin. These days Moco doesn't even try on mobile anymore (hint, there is no performance testing at all on arm in https://arewefastyet.com/# https://arewefastyet.com/#). The desktop Firefox front-end didn't evolve so much during the FxOS days but these was not the same team either... and you would notice that key people leading Fx front end have changed since.
- chc 9y ago
  $400 million looks like a lot until you remember that Apple have $267 billion in cash reserves. The Mozilla Foundation's entire annual revenue isn't even a fifth of a percent of what Apple have just sitting around because they can't find a better use for it. The fact that Mozilla are able to punch even this far above their weight is kind of impressive.

bzbarsky 9y ago

Mostly what the benchmark shows is that the benchmark in question measures one specific thing which doesn't have a JIT fast path in Firefox yet, but measures it multiple times in different ways... [Edit: Actually two things: hot loops in the same function as a class definition, and derived classes that use "super".] Chances are whatever you see on your app is a different issue. I'd be happy to profile and file bugs as needed if you can get me a link that shows the problem on your app.

jfbastien 9y ago
Interesting. What is that thing exactly? Is there a bug we can follow?
- bzbarsky 9y ago
  Actually, I guess there are two things: 1) If you have a class definition inside a function, that function doesn't get jitted. The functions in the class definition itself can still get jitted. 2) Class methods that use super don't get jitted at the moment. So if your class definitions are not in the same function as your hot code and don't use super, you get fast paths. Otherwise some things will run in the interpreter. The tracking bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 https://bugzilla.mozilla.org/show_bug.cgi?id=1167472 and https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 https://bugzilla.mozilla.org/show_bug.cgi?id=1167472#c13 is what the above summary is based on.

omnimus 9y ago

It strange i dont know in which world i am living but i always have opposite feeling. I use lot of tabs and well chrome might start faster but if you have 30 tabs open it slows my whole computer. With firefox it seems all fine.