On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote:
On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione <kmagli...@mozilla.com> wrote:
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.
WebIDL bindings are optimized for speed above all else, and that shouldn't
have to change to mitigate overuse.
My point is that if we're deciding that we need to make a trade-off between
speed and compiled binary size, I think that we're better off doing that by
changing how we generate the bindings for interfaces that we decide are not
performance sensitive than deciding to use XPIDL for them. If nothing else, it
makes it easier for us to make the change for a particular interface, or to
change our mind.
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.
I am basically worried about two things:
(1) Wholescale conversions of big interfaces in the name of cleanup and
ergonomics. See bug 1341546 for an example.
Heh. It's interesting that you bring that interface up, because I've been
thinking for a long time that it's one of the most obvious examples of
something we should convert to WebIDL. We use it all over the place, and it's
one of the places that I see XPConnect overhead turn up most for in profiles.
I'm not entirely sure whether a review gate is necessary. But at the very
least, I want to establish a consensus around that we should only use
WebIDL to expose internal interfaces if one of the following applies:
(A) The API is likely to be called hundreds of times under normal browser
execution.
(B) The API is associated with a DOM object, and thus adding it
[ChromeOnly] to that interface is particularly convenient.
(C) The API uses complex arguments like promises that XPIDL doesn't handle
in a nice way.
Opinions?
I don't really have a problem with these criteria. That's more or less what I
consider when deciding how to implement bindings.
But I'd really rather we didn't have to make this trade-off. There's no
fundamental reason WebIDL bindings have to have more code size overhead than
XPIDL bindings. The implementation details are almost completely separated
from the consumers, and if at some point we decide the overhead is becoming a
problem and we need to make a trade-off, we can always change the
implementation that we use for interfaces we think are not performance
critical.
On Thu, Mar 8, 2018 at 3:16 PM, Stuart Philp <sph...@mozilla.com> wrote:
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.
The problem is precisely that it's gradual - a few kilobytes at a time,
certainly nothing to trigger our alerts. Waiting for it all to pile up and
then launching a herculean effort to move things _back_ to XPIDL would be a
huge waste of time, which is why I'm trying to address the problem now.
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
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
It is practically impossible to teach good programming style to
students that have had prior exposure to Basic; as potential
programmers they are mentally mutilated beyond hope of regeneration.
--Edsger W. Dijkstra
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
