This is really interesting, thanks for looking at this!
On 03/01/2018 22:09, Gabriele Svelto wrote:
This would have quite a few coding benefits:
- It would make it far easier to retire/rename a topic, since ... JS would
throw.
Why would it? I think it would pass undefined (as the topic wouldn't
exist on the "ObserverTopics" object) which I expect would get coerced
by xpconnect to just '0'. Unless we either use a Proxy for the JS
implementation that throws when you access an unknown property (which
would be runtime-expensive) or unless WebIDL provides a way to do this
that avoids the coercion when passing it to an observer service method,
and instead throws from that method if it gets passed `undefined` for a
topic.
It would also help with code size, performance and memory use:
So, one thing that I have been thinking about in relation to
https://bugzilla.mozilla.org/show_bug.cgi?id=1425466 is that the
observer service when invoking lots of JS observers currently does
(something like) this:
- get called from a single place (in JS/C++, doesn't matter much);
- get list of observers
- call each observer with the same arguments. For JS observers, this
means crossing from C++ to JS, and back with exceptions or whatever
for cases where there are "many" observers for a single topic (x-ref
https://bugzilla.mozilla.org/show_bug.cgi?id=1195386 ), this is going to
be inefficient because we go back and forth across the xpconnect
boundary N times for N observers, every time getting JS values/wrappers
for the subject and data, etc. etc. This would be better if there was a
JS side to things that handled all the dispatching to JS observers, and
would "forward" exactly 1 observer to the 'real' observer service.
I'm not sure if the costs justify optimizing this. I haven't had time to
profile this or see how often this happens if you don't run a browser
session with hundreds or thousands of tabs (and tbh, most if not all the
consumers which add that many observers ought to be optimized to Not Do
That anyway).
> - One would not be able to add/remove/change a topic in an artifact
> build. I'm not sure how many JS-only users of the observer service there
> are but if they're not many then this wouldn't be a big deal.
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver&case=false®exp=false&path=
-- sync, the add-ons manager, session store, etc. etc.). We run into
this problem with other things as well - telemetry being one that
currently does something like what you propose (so we can't change it in
an artifact build and that's pretty annoying) and I know Nicholas
Nethercote (CC'd) has been looking at making the prefs behave similarly.
Ideally, I would like a solution where especially JS-only observer
topics don't require a non-artifact build. A JS forwarder for the "real"
observer service may help with that goal, by making the "new" arguments
into strings transparently, and using the same string as a webidl name
property for artifact builds. This would mean "new" JS-only observer
calls in an artifact build would be slower than the int-based "real"
ones (and would perform "normally" once you actually did a "real" build,
ditto for distributed stuff). I think that's an OK trade-off.
Put differently, if we end up in a place where touching any prefs,
telemetry or observers means frontend folks can't use artifact builds,
that'll have significant negative impact on our development speed, as
well as the ability of new contributors to build and contribute code to
Firefox.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
