SoylentNews is people
SoylentNews
from the bring-back-Netscape-Navigator dept.
Google has reportedly made the Chrome web browser significantly faster by using a feature of Microsoft's Visual Studio compiler:
Starting with the Chrome 53 release of 64-bit Chrome and version 54 of the 32-bit version, Google started using Microsoft's so-called Profile Guided Optimization technology to speed up startup times (by 17 percent), new tab page load times (by almost 15 percent), and overall page load times (by 6 percent) in Chrome.
Profile Guided Optimization (PGO) is a feature of Microsoft's Visual Studio developer tools that measures how users actually interact with an application. It then uses this training data and re-compiles the application with a focus on optimizing the most often used functions of the application.
Also at ZDNet.
(Score: 3, Touché) by bob_super on Wednesday November 02 2016, @07:22AM
> tools that measures how users actually interact with an application
Cool, what hidden feature do people really do with their browser, which major players will finally focus on for optimization?
> speed up startup times (...), new tab page load times (...), and overall page load times
[facepalm]
(Score: 2, Informative) by Anonymous Coward on Wednesday November 02 2016, @08:22AM
But hey, the tool detected that people start the browser, open new tabs and load pages! Who would have thought? ;-)
But more seriously: This description of the tool, while not strictly speaking wrong, is utterly misleading: It doesn't figure out what high-level features the users use, it figures out how often low-level code paths are taken. For example, assume you've got a conditional in your code, in the form: "if (some condition) then (do something) else (do something else)". Now code is linear inn memory, therefore one of the alternative code paths needs to be jumped to, which is more costly than just continuing (well, with modern processors using branch prediction, things get more complicated, but the fundamental principle remains the same). So it makes sense to jump for the branch that is less often executed. But which one is it? The compiler needs to know to produce optimal code.
In some cases, it's easy to guess, and can be hand-annotated (for example, in "if (an error occurred) then (handle error) else (continue operation)" you'd hope that the condition "(error occurred)" is rare, therefore "(continue operation)" should get preferred treatment. In other cases it's not so easy to guess. And even in cases where it is easy to guess, annotating the code means additional work that will only be justified if that single condition will give a considerable speedup, which will rarely be the case.
The profiler, however, does an automatic analysis of the code paths (so, not much manual work; basically you have to make a special profiling build and then run the program often enough to get a reasonable statistics), and therefore will give information on any and all branches (and other places where compiler decisions affect performance), so without too big effort you may get lots of micro-optimizations that each in isolation don't provide much speedup, but which together may give a considerable speedup.
Note that this is not about optimizations humans do (although they of course can also use the profiler data to see on which parts of the code they should concentrate to improve performance), but about optimizations the compiler does.