Re: Browser Architecture Newsletter #7 (S02E02)
> On Sep 20, 2018, at 9:10 AM, Kris Maglione wrote: > > On Thu, Sep 20, 2018 at 09:02:09AM -0700, Nicholas Alexander wrote: >> On Thu, Sep 20, 2018 at 7:25 AM smaug 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On Thu, Sep 20, 2018 at 09:02:09AM -0700, Nicholas Alexander wrote: On Thu, Sep 20, 2018 at 7:25 AM smaug 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On Thu, Sep 20, 2018 at 7:25 AM smaug wrote: > On 09/20/2018 04:21 PM, Mike Hommey wrote: > > On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote: > >> On 09/19/2018 08:34 PM, Nicholas Alexander wrote: > >>> 2. > >>> > >>> Making the main browser window be an HTML document with (mostly) > HTML > >>> DOM elements instead of a XUL document with (mostly) XUL DOM > elements. > >> > >> It is still mystery to me how the performance can be anywhere close to > XUL when > >> starting browser or opening a new window. > >> XUL's prototype cache was explicitly added because of performance long > ago. > >> That is why we need to only load already parsed document in a binary > format, > >> or in case of new window, just clone from the prototype. > >> Last time I heard, moving to use HTML document does cause significant > regressions. > > > > 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). In any case, I do not personally know enough to put the regressions you're highlighting into context, so I'll leave that for others. Let me leave with an honest question: why can't we do the equivalent of the XUL prototype cache for the browser HTML document window? Best, Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On 09/20/2018 04:21 PM, Mike Hommey wrote: On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote: On 09/19/2018 08:34 PM, Nicholas Alexander wrote: 2. Making the main browser window be an HTML document with (mostly) HTML DOM elements instead of a XUL document with (mostly) XUL DOM elements. It is still mystery to me how the performance can be anywhere close to XUL when starting browser or opening a new window. XUL's prototype cache was explicitly added because of performance long ago. That is why we need to only load already parsed document in a binary format, or in case of new window, just clone from the prototype. Last time I heard, moving to use HTML document does cause significant regressions. 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. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote: > On 09/19/2018 08:34 PM, Nicholas Alexander wrote: > >2. > > > >Making the main browser window be an HTML document with (mostly) HTML > >DOM elements instead of a XUL document with (mostly) XUL DOM elements. > > It is still mystery to me how the performance can be anywhere close to XUL > when > starting browser or opening a new window. > XUL's prototype cache was explicitly added because of performance long ago. > That is why we need to only load already parsed document in a binary format, > or in case of new window, just clone from the prototype. > Last time I heard, moving to use HTML document does cause significant > regressions. 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. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser Architecture Newsletter #7 (S02E02)
On 09/19/2018 08:34 PM, Nicholas Alexander wrote: 2. Making the main browser window be an HTML document with (mostly) HTML DOM elements instead of a XUL document with (mostly) XUL DOM elements. It is still mystery to me how the performance can be anywhere close to XUL when starting browser or opening a new window. XUL's prototype cache was explicitly added because of performance long ago. That is why we need to only load already parsed document in a binary format, or in case of new window, just clone from the prototype. Last time I heard, moving to use HTML document does cause significant regressions. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Browser Architecture Newsletter #7 (S02E02)
Browser Architecture Newsletter #7 (S02E02) It’s been a long six months since the last Browser Architecture newsletter <https://mail.mozilla.org/pipermail/firefox-dev/2018-March/006272.html>. Short and sweet and no theme for this newsletter. XUL/XBL Replacement The XUL/XBL replacement project is churning ahead. There are two major goals right now: 1. Replacing XBL bindings with Web technologies like Custom Elements; and 2. Making the main browser window be an HTML document with (mostly) HTML DOM elements instead of a XUL document with (mostly) XUL DOM elements. There’s been progress on both fronts; more details can be found in the latest XUL/XBL Replacement newsletter <https://mail.mozilla.org/pipermail/firefox-dev/2018-August/006760.html>. Fluent Fluent is the localization system that Firefox intends as the replacement for XML and DTD files. The first Firefox feature to convert to Fluent is about:preferences <https://bugzilla.mozilla.org/show_bug.cgi?id=1415730>, which now has only 10 old-style strings remaining (down from an initial 1100 old-style strings)! Behind the scenes, a big hurdle in the path to smooth future conversions landed recently: Bug 1455649 <https://bugzilla.mozilla.org/show_bug.cgi?id=1455649> integrated localization deeply into the (chrome-only) DOM. Sync and storage rkv <https://github.com/mozilla/rkv> is a new lightweight Rust key-value storage engine built on top of LMDB. We’re looking at using it for a variety of components, including XULStore and the search cache. In order to let others “kick the tires” easily, Myk Melez landed rkv into mozilla-central <https://bugzilla.mozilla.org/show_bug.cgi?id=1445451>, although it’s not yet compiled into Firefox for Desktop. If you’ve got some keys and some values that you’d like to persist efficiently, I know a guy. Mentat <https://github.com/mozilla/mentat> was to be our heavyweight store for user data that we wanted to sync between devices. But we couldn’t bring the technology to a meaningful market quickly enough, so we’re not pursuing Mentat any further <https://mail.mozilla.org/pipermail/firefox-dev/2018-September/006780.html>. The Application Services team is rapidly building a cross-platform Sync 1.5 stack in Rust <https://github.com/mozilla/application-services> and that will be the vehicle for improving the Firefox Sync experience for the foreseeable future. Node time! We have made significant progress toward enabling Node.js tooling in the Firefox build system. This effort truly spans teams and projects: the build maintainers and the browser architecture team made a case for Node.js and set technical direction; the GitHub Integration working group incubated the effort; and Firefox feature teams including the Activity Stream team (Dan Mosedale), the ESLint team (Mark Banner), and the Devtools team (Jason Laster and Alexandre Poirot) are driving the work across the line! The build now requires Node.js by default <https://bugzilla.mozilla.org/show_bug.cgi?id=1483595>. Up next is adding the ability to use this from moz.build files and then drafting proposals for how we’d like to manage node_modules. The first consumers will be the Firefox debugger, Activity Stream, and the ESLint integration. Thanks to the many folks who have helped and continue to help this project forward. Firefox technical leadership in the module ownership system Since the last newsletter the new Firefox Technical Leadership Module has been formed. You can see some of the discussion around it and its purpose in the governance thread <https://groups.google.com/forum/#!msg/mozilla.governance/YTTqUzWaJ00/-MopTK71AwAJ>. The FTLM has representation from the Browser Architecture team in the form of Dave Townsend. You can always reach us on Slack or IRC (#browser-arch). This newsletter is also available as a Google Doc <https://docs.google.com/document/d/1MR86LaXGJwVYrJ-Z7urFZUwB8xdYM2tlPwA9nQ_vMIE/edit> . Nick (who promises a theme next time) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
