New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome 79 - 96 results #683
Comments
wow, is 79 really 40% slower at dom creation than 75 😮 . might be interesting to go back even further to see where the inflection point was. maybe now that they have huge market share "fastest browser" marketing has greatly diminished ROI? is every version tested with the same OS-level Spectre and Meltdown mitigations, cause if you're just plotting historical data, then this could easily be a large factor (and worth re-testing v75 again). on top of that, v8/Blink itself might be disabling some JIT paths that lead to possible timing attacks, too. hard to say what we're getting in exchange for the perf loss (hopefully security). cc @paulirish (just in case). |
@leeoniya The os patch level and drivers surely advanced between Chrome 77, 78 and 79 results, yet all runs were with mitigations=off. But I took a closer look when Chrome 77 results were bad. I downgraded then chrome to 75 and 76 and confirmed the regression there (see #641). I haven't found an easy way to downgrade chrome on ubuntu so I havent repeated it for chrome 78 and chrome 79 yet - if anyone knows better please let me know and I'll perform the downgrade. |
Yeah 75 was a good one.. but if you go back further it just goes in cycles. I'd need to look it up for exact versions but there were some pretty slow versions in the early 70s. |
I couldn't downgrade chrome on ubuntu nicely, so i decided to try to downgrade on windows (from https://www.slimjet.com/chrome/google-chrome-old-version.php), which works better. I only had time to run two versions so I took Chrome 75 and the current version and checked that the performance difference is not due to system configuration. Chrome 75 (slimjet installer): Chrome 79 (google installer): As a side note: Chrome 79 reports two paint events whereas previous reported only a single paint event (but they are close enough not to matter in terms of difference to chrome 75). |
Just for the record. On ubuntu the test driver extracts the following from the timeline: |
Here are some more numbers extracted manually from the timeline (open chrome + dev tools, start profiling and reload page then click on append 1,000 rows and extract the duration from the timeline like in the screenshots above):
Observations:
|
haven't done extensive perf testing in Chrome 80 yet, but initial results seem to indicate a continued downward perf trend. my baseline bench [1] went from 42ms -> 55ms init (with significant variation). meanwhile, Firefox is at 33ms with little-to-no variation. might be interesting to see what can be gathered via https://github.com/microsoft/playwright, though this would be quite the undertaking. |
Results for Chrome 80 are now published |
I opened a chrome bug some time ago: https://bugs.chromium.org/p/chromium/issues/detail?id=1035938 |
no experience getting automated profiles, but they have some neat stuff in the works: https://profiler.firefox.com/, https://imgur.com/a/3fXISLP. unfortunately, it was not originally slated to be integrated into devtools. but i had a discussion [1] with them and think it lit a fire under some butts [2]. we'll see what comes of it. [1] https://old.reddit.com/r/javascript/comments/ecyhmr/mozilla_survey_how_can_devtools_support_you/fbez5c0/ |
(Joining from the Firefox side, sensing a 🦊 signal) @leeoniya I always got 🔥, maybe not where you tried to light it 😏 – glad you hear that you are excited about it coming! We are on track to get it into DevTools in H1 and hopefully all the way to release. The easiest way to record a performance profile that can be loaded into profiler.firefox.com would be startup profiling; which means you'll get data as well from Firefox startup; but with https://profiler.firefox.com/docs/#/./guide-startup-shutdown explains to enable env variables. |
@RUSshy yeah i had same concerns above: #683 (comment). is there any way to get reproducible builds of Chrome rather than Chromium? if not, then the whole exercise might not be too meaningful. FWIW, Chromium builds [1] have always been slower for me than Chrome Stable releases. |
Repeated today:
(Yes - the 6 msecs were really reported in two runs!)
|
Sigh... I miss Chrome 75. Here's to Chrome 81 hopefully reversing this trend (not that I've had the chance to test it yet). |
well i finally got some movement by floating it to the HN front page: https://news.ycombinator.com/item?id=22267547 looks like they root-caused it [1] to rolling out LayoutNG: https://developers.google.com/web/updates/2019/06/layoutNG but there's been no updates since late feb. ¯\(ツ)/¯ [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1035938#c20 |
Results for Chrome 81 are published: https://krausest.github.io/js-framework-benchmark/2020/table_chrome_81.html Please note that chrome 81 ran on Ubuntu 20.04-beta, such that the chart now includes the OS used: |
Results for chrome 83 are up: |
Hmm more or less back to Chrome 77 other than remove row. Remove row is interesting. Keyed moving the rows up is more performant than non-keyed replacing the data and removing the last row. Something must have fundamentally changed in how Chrome handles layout changes. Memory is also down to unprecedented levels. I feel like it was only a year ago most libraries were at about 3mb ready memory. Now 80% of libraries are below 1.4mb. Even some of the worst libraries on memory are at about 50% of what they were (Like KnockoutJS was over 20mb on some tests now tops at 11.8mb) |
i think they've been focusing a lot on reducing v8's/Chrome's mem footprint, since Chrome is famous for its RAM hunger. |
@leeoniya That makes sense. Although I wonder if there is a shelf. Look what has happened to Benchmark 7 the 10k rows. Most of the performant libraries more or less stayed the same. But the others dove right off the deep end. Like things that used to be 1.8 seconds are now 4 seconds. Those results seem to have large +- as well. I wonder if it is the browser or just the test driver. I guess the issue with React Djinn could be related. |
I decided to withdraw the results for chrome 83 due to #741 . |
Chrome 87 is reportedly very fast. In this benchmark almost as fast as chrome 75... (to be fair, remove it really fast) Results for chrome 87 are published. |
Chrome 88 results are up https://krausest.github.io/js-framework-benchmark/2021/table_chrome_88.0.4324.96.html |
Chrome 89 results showing a bad trend... |
Chrome 90 is very special. It looks like it's the first version that beats chrome 75 in every aspect and is really pretty fast. It looks so good that I've published the results only as unofficial 😄 and take counsel with my pillow: I haven't read anything about much improved performance in Chrome 90. Did I miss something? P.S: As you can see I switched to Fedora 34. I thought about running the benchmark on Fedora 33, but it had an hard X11 crash. I compared results from the unfinished Fedora 33 run and the completed Fedora 34 run and they are close, maybe with a small advantage for Fedora 34. But the effect above is not from the system upgrade, but from the chrome update) |
Chrome 90 includes V8 release I haven't looked over the actual V8 git log but I believe it includes this particularly exciting improvement: https://v8.dev/blog/adaptor-frame. |
It's awesome we are finally back at better than Chrome 75 performance across the board. It's been almost 2 years. |
Chrome 91 results are in: https://krausest.github.io/js-framework-benchmark/2021/table_chrome_91.0.4472.77.html Running the benchmark wasn't completely flawless. I git several "The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed." errors and had to rerun the benchmark for those cases. |
Chrome 92 results are in. Partial update is significantly slower than on chrome 92. I'm looking for feedback for those results - I plan to publish them as official results tomorrow. Results are published: https://krausest.github.io/js-framework-benchmark/2021/table_chrome_92.0.4515.107.html |
Yeah that is just bizarre. One thing I didn't notice for years was the vanillajs version isn't even minified. It's literally just a hand written JS file which is why other implementations come close in size. When you minify it Vanilla is clearly smaller. But it also suggests to me there is not much reason for it to be slower than anything else. It does create some DOM nodes on initial execution to make the templates that will be cloned but so do a number of other frameworks not showing the slow startup. |
I'll have to check whether the chrome or the lighthouse update caused that behaviour. But I'm afraid I won't be able to take time to analyze this the next two months. |
For some reason, Sycamore's results in Chrome 92 are way better than in Chrome 91, especially for create 10000 rows. It has improved by about 3x. It used to be the Major GC that took up a lot of time. Maybe the GC is lazier? Not quite sure what happened. |
yes, it's looking lazier since 91. see also #916 |
Results for chrome 93 are available: https://krausest.github.io/js-framework-benchmark/2021/table_chrome_93.0.4577.63.html |
we should probably close out https://bugs.chromium.org/p/chromium/issues/detail?id=1035938 at this point? |
Hi, I was going through our backlog of Apologies I missed the bug the first time round (it was inadvertently taken out of the triage queue). The initial performance regression was likely (in part) due to us removing a very particular type of cache. Historically when measuring inline content (text) browsers will measure on a word-by-word basis, to build up a paragraph of text. Essentially we'd build up a: This design is simple, but has its drawbacks - it cannot handle some fonts (e.g. if the kerning table has spaces in it), or handle complex text particularly well. This means that users who use these languages/scripts (Thai, Persian) typically have had significantly worse performance as opposed to Latin scripts (even with Latin scripts, some languages e.g. German make the word cache less effective). Today Blink will shape the whole paragraph of text once which we found has higher throughput on average, and for most pages faster than checking the word-shape-cache for each word (more on this in a second). We don't really attempt to cache any shape results from harfbuzz (except when appending text). We found that some microbenchmarks did get slower however. We found that these microbenchmarks were typically using a fixed small dictionary for words. This means that the word shape cache was typically super effective at these microbenchmarks, however the new system less so as we'd shape everything on a per paragraph basis (everything within a table cell in this case). For this specific benchmark I believe the word dictionary is relatively small ~30-50 words for the 2nd column. The numbers (1st column) is better but again if removing/inserting the number would hit the same spot in the cache. Removing this cache is a tradeoff (some pages/webapps do use a lot of the same repeated words!) but the speedup and complexity reduction for other scripts was significant (as in sometimes a couple of orders of magnitude in performance improvement). Some additional slowdown was likely due to the "Legacy<->NG" bridge we build in our layout system, transitioning between the two layout systems was more expensive that if it kept within the same system. The performance improvement around the ~M86 range was likely due to some optimizations we made to inline layout (collapsing things into a flat list rather than a tree heirarching for inline content). Finally the performance improvement around M91 was likely due to us moving tables completely onto the new layout system. This removed the bridge (not that much of an improvement by itself). Tables are historically very complicated, we have some additional caching from our new system which likely helps slightly as well as just higher raw throughput in the table layout code due to better data-structures. (there are some really complex optimizations that we could add specifically for tables, which would likely help significantly the remove/create/replace benchmarks, but these would be super difficult to maintain). Unsure what was the cause for the significant drop in "remove" around M83. Next year there are some more improvements that we'll be able to take, but nothing super significant (e.g. ~5% improvements here and there). In the next couple of releases there may be a regression due to more rendering data-structures (style, layout, paint) moving onto our garbage collector for security reasons. We've seen this regress some microbenchmarks on the order of ~10-15%. Typically this is due to some GC pauses, some of this will be eventually mitigated due to making the GC faster (marking off-thread etc). Ian |
Chrome 96: There's a continuing trend that chrome appears to becoma a little slower for this particular benchmark. |
Happy new year! This thread got pretty long so we'll continue 2022 results in #984 |
Results for Chrome 79 are online. Sadly this benchmark reports one again worse numbers for a newer chrome version:
The text was updated successfully, but these errors were encountered: