4 ms·

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, wh

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).
  - pjmlp 9y ago
    I guess you missed the part where the OP wrote "while Chrome works just fine.", yet his/her coding is to blame. No wonder people move to other browsers instead.
    - mrout 9y ago
      I guess you missed the part where it was explained several times in this thread that Chrome promotes things that are slow everywhere else.
- cpeterso 9y ago
  Can you share a link to your web app? Mozilla developers are very interested in profiling performance problems on real sites. You might want to check in Firefox's about:support page to see if there are any warnings about your GPU being blocked for driver issues. Feel free to email me if you'd prefer not to share a link in a public HN comment. See my HN profile for my Mozilla email address.
- littlestymaar 9y ago
  Maybe you're hitting the same slow path in Firefox than this benchmark (see [1]). I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it. When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it). [1]: https://news.ycombinator.com/item?id=14495275 https://news.ycombinator.com/item?id=14495275

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).
- pjmlp 9y ago
  I guess you missed the part where the OP wrote "while Chrome works just fine.", yet his/her coding is to blame. No wonder people move to other browsers instead.
  - mrout 9y ago
    I guess you missed the part where it was explained several times in this thread that Chrome promotes things that are slow everywhere else.
cpeterso 9y ago
Can you share a link to your web app? Mozilla developers are very interested in profiling performance problems on real sites. You might want to check in Firefox's about:support page to see if there are any warnings about your GPU being blocked for driver issues. Feel free to email me if you'd prefer not to share a link in a public HN comment. See my HN profile for my Mozilla email address.
littlestymaar 9y ago
Maybe you're hitting the same slow path in Firefox than this benchmark (see [1]). I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it. When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it). [1]: https://news.ycombinator.com/item?id=14495275 https://news.ycombinator.com/item?id=14495275