Just to echo what David said, PGO builds cause amorphous stability and even graphics/layout bugs (for instance bug 831296) that we're forced to investigate in engineering and QA for a specific release, even though the issues aren't typically caused by actual in-product regressions. Additionally, inconsistent PGO builds have been known to cause one-off crash spikes (like bug 799118) which prove to be a waste of time for our engineering/stability/QA groups.
It's definitely a world of pain that we should avoid if at all possible. I'm of the opinion that we should nuke it from orbit (option #1) if there's no obvious/significant user performance gains. -Alex On Jan 31, 2013, at 11:49 AM, David Anderson <bailo...@gmail.com> wrote: > On Thursday, January 31, 2013 8:54:50 AM UTC-8, Ehsan Akhgari wrote: >> On 2013-01-31 10:59 AM, ... wrote: >> >>>> 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. >> >>> >> >>> This seems to indicate our current coverage isn't oriented toward >> >>> performance gains users will see, and that there are potential >> >>> gains to be found. All the more reason to keep pgo around a while >> >>> longer and figure out how we can simplify testing with different test >> >>> runs. >> >> >> >> There are costs to keeping PGO enabled, and while we can argue that we >> >> _could_ be getting more PGO gain by providing a better profile, one >> >> could counter-argue that engineers can spend more time optimizing other >> >> things if they didn't need to find the perfect profile (which is sort of >> >> a black magic.) >> >> >> >>>> We should also remind that there would be an infra load win from >> >>>> disabling Windows PGO builds. >> >>> >> >>> IMHO, if it's a choice between infra load and better performance >> >>> in the end product, performance should win out. >> >> >> >> I agree, infrastructure load is not relevant to this conversation. >> >> There are tons of other ways to improve that besides disabling PGO. >> >> >> >> Cheers, >> >> Ehsan > > I'm weighing in a little late here, but from the JS team's perspective, PGO > is a nightmare. It introduces subtle compiler bugs (often topcrashes) that > are extremely difficult to track down. We end up littering the codebase with > de-PGO hints. To date I have yet to see a PGO-only crash that manifests in > the JS engine, that was not directly caused by PGO. > > Related, I don't think MOZ_LIKELY/UNLIKELY are either a good idea or would > cover the PGO gap. PGO does way more than just branch prediction, it has all > sorts of speculative partial inlining and register allocation tricks. (That, > unfortunately, are buggy.) > > Anyway, disabling PGO is music to my ears - I'd bet money that our overall > crash-stats will improve. > > -David > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
