On 1/31/2013 6:39 AM, jmath...@mozilla.com wrote: >> We then tried to get a sense of how much of a win the PGO optimizations >> are. Thanks to a series of measurements by dmandelin, we know that >> disabling PGO/LTCG will result in a regression of about 10-20% on >> benchmarks which examine DOM and layout performance such as Dromaeo and >> guimark2 (and 40% in one case), but no significant regressions in the >> startup time, and gmail interactions. Thanks to a series of telemetry >> measurements performed by Vladan on a Nightly build we did last week >> which had PGO/LTCG disabled, there are no telemetry probes which show a >> significant regression on builds without PGO/LTCG. Vladan is going to >> try to get this data out of a Tp5 run tomorrow as well, but we don't >> have any evidence to believe that the results of that experiments will >> be any different. > > Are the test run stats we're using here published somewhere? We should be > tracking all this testing some place (a wiki page maybe?) so people can do > their own investigation. > > I've always wondered if the tests we run during the pgo phase are sufficient > to get good coverage over the entire app. Is it possible that we don't see > gains in other areas because our pgo tests don't hit those areas? (I think > there was an effort under way to expose these tests so they could be modified > in try runs for better experimentation.) > > Generally I would make disabling pgo the last option after exhausting all > other options. > As a historical note, when we first enabled PGO support for Windows our profiling scenario was "start Firefox, wait 10 seconds, shut down Firefox". Enabling PGO with this profiling run provided us with 20-25% perf improvements in many of our benchmarks on Talos. We later changed it to the current set of profiling data[1] (Blueprint CSS samples, the SunSpider benchmark), and there was almost no visible change in the Talos numbers. I'm sure for very specific benchmarks we could improve perf by adding those things to the profiling run, but it's a very delicate art. The optimizer has to balance code size against speed, and it's not always obvious which way makes things better. (For example, we historically built with -Os + a few extra optimize flags on Linux instead of -O2 because producing smaller code generally made us faster than optimizing everything for speed.)
-Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=472706 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
