> On Sep 20, 2018, at 9:10 AM, Kris Maglione <[email protected]> wrote: > > On Thu, Sep 20, 2018 at 09:02:09AM -0700, Nicholas Alexander wrote: >> On Thu, Sep 20, 2018 at 7:25 AM smaug <[email protected]> wrote: >>> > I'm reminded of https://bugzilla.mozilla.org/show_bug.cgi?id=618912 but >>> > IIRC there were similar experiments back then on desktop, and basic html >>> > chrome was significantly faster than basic xul chrome. >>> That bug seems to be more about the layout. >>> >>> >>> https://screenshotscdn.firefoxusercontent.com/images/d1753829-3ebd-4c42-a757-14757051accf.png >>> is >>> the latest numbers I've seen. That isn't pgo, so may or many not be very >>> accurate, but the regression is >>> very significant. >>> >> >> I'm not expert in these areas, so I hope the experts chime in, but I think >> there are lots of trade offs here. I believe that you are correct: the XUL >> prototype cache and similar mechanisms significantly impact browser startup >> and related metrics. But there is a general belief, which I do not have >> references for, that the HTML widget set is either faster than or will be >> faster than the XUL widget set. Certainly folks believe that effort should >> be put into optimizing core Web Platform technologies (rather than >> Mozilla-specific extensions). > > We can't afford a startup or window opening performance regression. If > switching to HTML gives us other performance improvements, that's great, but > it can't come at the cost of performance in other areas that we've worked so > hard to get into reasonable shape.
To be clear: we’re not going to ship a new browser window with performance regressions. Right now we are working on fixing broken tests in browser.xhtml so that we can do an apples-to-apples performance comparison with browser.xul. Once we do that we’ll start fixing performance regressions (if any). This work is tracked in Bug 1453783. I did some talos pushes to get an idea of the magnitude of regressions to expect when disabling individual parts of the prototype cache while using browser.xul: - nsXULPrototypeCache::PutXBLDocumentInfo and nsXULPrototypeCache::PutStyleSheet are the most impactful parts of the cache, and they continue to work even in chrome HTML documents AFAICT. Disabling them causes 5-20% regressions on a bunch of tests (https://mzl.la/2pq3Sh5 and https://mzl.la/2NWXJ9L). - nsXULPrototypeCache::PutScript seems to have no impact on talos (https://mzl.la/2xp1BXK). - Disabling nsXULPrototypeCache::PutPrototype causes the ~3% tpaint and ts_paint_heavy regressions that smaug is pointing to (https://mzl.la/2xq1JpI). That's disabling the prototype cache while still using a XUL document, so not the same environment we’d be in with an HTML document. Brian _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
