3 ms·

Does anyone have a reliable place for browser javascript benchmarks? Some searching only brought up a range of promotional type stuff from browser makers and ol

by matt2000 11y ago

Does anyone have a reliable place for browser javascript benchmarks? Some searching only brought up a range of promotional type stuff from browser makers and old articles. Thanks!

Klathmon 11y ago
https://arewefastyet.com/#machine=29 https://arewefastyet.com/#machine=29 has most popular benchmarks across most JavaScript eninges on multiple platforms Edit: actually this view is probably better for people who don't care about JavaScript engine internals: https://arewefastyet.com/#machine=31 https://arewefastyet.com/#machine=31
- swampthinker 11y ago
  What's Chrome turbofan?
  - Klathmon 11y ago
    It's Chrome's (or more accurately v8's) new-ish optimizing compiler. For some of the tests they like to disable the non-optimizing compiler to see how just the optimizing one runs alone with no fallback.
  - bluejekyll 11y ago
    Dead it looks like.
    - deleted 11y ago
      [deleted]
- Joeri 11y ago
  The focus on JS benchmarks is becoming ludicrous. By far the biggest performance issue is DOM/CSS layout. JS is so fast on all browsers that the performance differences don't matter at all anymore, except for initial load (and if you're loading that much code on initial page load, you should re-evaluate your architecture).
  - Klathmon 11y ago
    I agree 100%, but they were asking for a place with JavaScript benchmarks, so I gave my favorite.
  - _greim_ 11y ago
    Modern frameworks have worked hard to mitigate DOM bottlenecks, thus pure JS bottlenecks are now a thing. Especially data-rich applications. Reflow and paint performance is still an issue but the focus on JS is worthwhile.
    - Joeri 11y ago
      Have you measured this? Do you actually build or use specific apps where the dominant factor is JS execution time and not layout or network time?
      - _greim_ 11y ago
        Yes. String-processing tweets (linkify and emoji-insert) and crunching numbers for time series line charts were two areas where we saw some lag. It was React so these bottlenecks were happening during virtual DOM rendering. And realizing GP was talking about client-side, but also don't forget server-side, where DOM doesn't exist and the hyper-focus on pure-JS perf is much appreciated.

Does anyone have a reliable place for browser javascript benchmarks? Some searching only brought up a range of promotional type stuff from browser makers and old articles. Thanks!

Klathmon 11y ago

https://arewefastyet.com/#machine=29 https://arewefastyet.com/#machine=29 has most popular benchmarks across most JavaScript eninges on multiple platforms Edit: actually this view is probably better for people who don't care about JavaScript engine internals: https://arewefastyet.com/#machine=31 https://arewefastyet.com/#machine=31

swampthinker 11y ago
What's Chrome turbofan?
- Klathmon 11y ago
  It's Chrome's (or more accurately v8's) new-ish optimizing compiler. For some of the tests they like to disable the non-optimizing compiler to see how just the optimizing one runs alone with no fallback.
- bluejekyll 11y ago
  Dead it looks like.
  - deleted 11y ago
    [deleted]
Joeri 11y ago
The focus on JS benchmarks is becoming ludicrous. By far the biggest performance issue is DOM/CSS layout. JS is so fast on all browsers that the performance differences don't matter at all anymore, except for initial load (and if you're loading that much code on initial page load, you should re-evaluate your architecture).
- Klathmon 11y ago
  I agree 100%, but they were asking for a place with JavaScript benchmarks, so I gave my favorite.
- _greim_ 11y ago
  Modern frameworks have worked hard to mitigate DOM bottlenecks, thus pure JS bottlenecks are now a thing. Especially data-rich applications. Reflow and paint performance is still an issue but the focus on JS is worthwhile.
  - Joeri 11y ago
    Have you measured this? Do you actually build or use specific apps where the dominant factor is JS execution time and not layout or network time?
    - _greim_ 11y ago
      Yes. String-processing tweets (linkify and emoji-insert) and crunching numbers for time series line charts were two areas where we saw some lag. It was React so these bottlenecks were happening during virtual DOM rendering. And realizing GP was talking about client-side, but also don't forget server-side, where DOM doesn't exist and the hyper-focus on pure-JS perf is much appreciated.