Firefox has done this since forever. It's why official builds will generally be faster than compiling from scratch yourself. I'm surprised Chrome wasn't already taking advantage of PGO.
10% faster is a pretty nice improvement, especially in 2020.<p>Here's a little Wikipedia stub about Profile-Guided Optimization, for those who'd like to read more about the technique.<p><a href="https://en.wikipedia.org/wiki/Profile-guided_optimization" rel="nofollow">https://en.wikipedia.org/wiki/Profile-guided_optimization</a>
Where are the profiles gathered from?<p>Did they just render the alexa top 1M sites and generate a profile from that? It would seem some bits of the codebase might only be exercised by real users (eg. touch input during a mobile game).<p>Did they instead gather PGO information from real users? If so, how did they do that in a way to not degrade performance too much while profiling, and maintaining user privacy (sequences and addresses of branches in some cases will reveal user data)?
> Tab throttling coming to Beta<p>This is nice, but I remember the pain trying make a multiplayer browser game run fine, even when you put it in a background tab. The problem is that the game had matchmaking, so players would change tabs while a match was found and for the first few seconds of the start of the game. While doing so, many of the CSS animations, sounds, JavaScript functions would be queued and all executed at once when you switched back to the tab, leading to a bad experience, or in some cases the game breaking. I assume this would only get worse with this tab throttling feature, but there are legitimate use cases where both developers and users would prefer a tab to still be running at normal speed even when not focused. We use this every day in desktop applications, where we start a game or some video encoding task and just let it run, non-throttled, in the background
Sigh. I used to love Chromium, when it was the new kid on the block. But now, because of this browser monoculture, I wouldn't use it even if it was far better than Firefox.<p>How times change.
What do these profiles consist of? Simply which branches are taken vs not taken? Or do they include a history (eg. if this branch is taken then that one will not be)?<p>Do they depend on the stack? Ie. when called from this function, that branch is always taken. That could encourage the compiler to inline the function so it can have a faster path on the branch.
It sees it was already used for windows: <a href="https://blog.chromium.org/2016/10/making-chrome-on-windows-faster-with-pgo.html" rel="nofollow">https://blog.chromium.org/2016/10/making-chrome-on-windows-f...</a>
Sorry for the elementary question...<p>...but is PGO referring to the compilation of Chrome itself, or the compilation of JavaScript on sites?<p>The blog post doesn't actually specify which compilation is being talked about, and page performance could obviously depend on either.
<a href="https://github.com/greatsuspender/thegreatsuspender" rel="nofollow">https://github.com/greatsuspender/thegreatsuspender</a> is great on Chrome (up until now).
I wonder how far we can take this sort of effort -- collect exact usage statistics for users and optimize software exactly for known usage patterns. Of course some statistical technique would be needed to deal with the long tail of usage patterns -- surely some program branches are used extremely rarely (or not even seen in collected samples), but you still wouldn't want them to be extremely slow (slower than necessary) or crash just because they're rarely used. The cumulative usage of many of those long tail events can be large.<p>Either (regularized) statistical inference of branches or something like assuming a baseline usage for every branch would be necessary.<p>This is all significantly complex of course, so for anything that are not the consumer megaprojects of software (browsers and operating systems?), I wonder if those tools could be used as well. Perhaps there could be some automated, anonymized usage reporting that does all this work?
Chrome 87 vs Safari 14 on macOS Big Sur benchmark:<p><a href="https://imgur.com/a/gUX2CIF" rel="nofollow">https://imgur.com/a/gUX2CIF</a><p>Safari/Webkit still the "fastest browser possible" on macOS.
This is supposed to roll out today: <a href="https://www.chromestatus.com/features/schedule" rel="nofollow">https://www.chromestatus.com/features/schedule</a>
Unrelated: my Chrome (on Windows) randomly freezes for 1-2 seconds whenever I focus one tab/window after I am away from it for a while. Is there any way to debug those kind of freezes?
Wonderful!<p>Chromium is an excellent project but just sometimes slow to adopt certain features.<p>I love chrome and chromium browsers, I hardly have any issues with them.<p>Unlike garbage FF and unreliable Safari