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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
