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