Generally I think we’d take performance and memory wins over installer size, but we monitor all three and if installer size grows (gradually) by an uncomfortable amount we ought to make a call on the trade off. We can bring it to product should that happen.
On Thu, Mar 8, 2018 at 6:07 PM Kris Maglione <kmagli...@mozilla.com> wrote: > On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > >I've seen a lot of momentum around migrating chrome-only XPIDL interfaces > >to WebIDL. I'm concerned that insufficient attention is being paid to the > >impact on our binary size. > > > >Fundamentally, the WebIDL bindings improve performance and spec > correctness > >at the expense of code size (and build times). This makes sense for things > >that are web-exposed or performance-sensitive. But since the webidl > >bindings are also more modern and easier to use, I'm concerned that people > >will use them indiscriminately for all sorts of internal APIs, and our > >binary will bloat by a thousand paper cuts. > > > >A WebIDL method binding can easily cost a kilobyte or more, depending on > >the number and types of the arguments. If we were to convert all of our > >existing xpidl methods, we could approach 10MB in added code size. > > I'm not sure how much of an immediate concern this should be. > > There are different costs to WebIDL and XPIDL bindings. WebIDL > bindings have more cost in terms of compiled code size. XPIDL > have greater costs in terms of performance and runtime memory. > I'm not sure exactly where the balance is as far as impact to > package size. > > And I think the benefits of WebIDL interfaces apply as much to > our internal uses as they do to web-exposed interfaces. The > amount of WebIDL overhead I regularly see in profiles can be > staggering. And XPIDL has enough foot-guns when interfacing with > JS that it's easy enough cause confusion and breakage even when > dealing with internal code. > > That said, if we're worried about binary size becoming an issue > for internal interfaces, there are things we can do to reduce > the code size of bindings. Particularly if we're willing to eat > the performance costs. > > At any rate, I don't expect us to convert anywhere near all of > our XPIDL interfaces to WebIDL. A lot of them don't need to be > exposed to JS at all. A lot of those should still go away, but > they don't need WebIDL bindings, just concrete native classes. > And a lot of the rest are little-enough used that I can't see > anyone spending the effort on converting them. > > >Gating on DOM peer review gave us some degree of oversight to prevent > >overuse. What should replace it? > > How much have DOM peers been focusing on preventing over-use, so > far? Granted, most of the WebIDL bindings I've created to date > have been to address measurable performance issues, but I've > never had a reviewer suggest that I should be worried about > over-use. > > >On Thu, Mar 8, 2018 at 2:01 PM, Kris Maglione <kmagli...@mozilla.com> > wrote: > > > >> It is now possible[1] to create chrome-only WebIDL interfaces in the > >> dom/chrome-webidl/ directory that do not require review by DOM peers > after > >> every change. If you maintain an internal performance-sensitive XPIDL > >> interface, or are considering creating one, I'd encourage you to > consider > >> migrating it to WebIDL. > >> > >> Some caveats to keep in mind: > >> > >> - Interfaces in this directory must be annotated with [ChromeOnly]. > >> Dictionaries, however, can be included without any special annotations. > >> > >> - If you are new to writing WebIDL files, I'd still encourage you to > ask a > >> DOM peer to review at least your initial check-in. > >> > >> - Please make sure that you do not attempt to expose any of the > interface > >> or dictionary types defined in these WebIDL files to web contexts, > through > >> interfaces defined in dom/webidl/. Doing so would require (and fail) DOM > >> peer review, in any case, but please think ahead. > >> > >> Thanks. > >> > >> - Kris > >> > >> [1]: As of bugs 1443317 and 1442931 > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
