4 ms·

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

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