1360736 - Look for ways to speed up the sync PContent LoadPlugin message

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, enhancement)

Description

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

According to Bug 1337058, making the LoadPlugin message async is very difficult due to webcompat issues. However, there are points at which it may take > 8s to run, blocking processes while it does. We should see if we can isolate those cases and figure out ways to optimize.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Kyle Machulis [:qdot] [:kmachulis] from comment #0)
> According to Bug 1337058, making the LoadPlugin message async is very
> difficult due to webcompat issues.

For more information on that odyssey, take a look at:

bug 998863
bug 1116806
http://dblohm7.ca/blog/2014/06/17/asynchronous-plugin-initialization-an-introduction/
https://people.mozilla.com/~aklotz/asyncinit/
http://dblohm7.ca/blog/2017/04/07/asynchronous-plugin-initialization-requiem/

Comment 2

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Ok, after reading those blog posts/slides, it sounds like this area has been mined pretty deeply already. :bsmedberg, is there anywhere else to look at this that didn't already happen, or should I just close this out and we'll wait for NPAPI death?

Comment 3

[Benjamin Smedberg]

I don't think we can get rid of the sync message completely, but we could try asynchronously pre-connecting Flash to content processes. We'd have to figure out exactly how to do that. Here are the complications:

* my understanding of this call is that it only happens ~once per content process per plugin, but if that's not true we shouldn't definitly make it so: there's no need to do this more than once.
** Exception: if Flash is upgraded during the session, we'd be calling this per plugin version.
* it would be nice not to launch the Flash process for users who typically don't need it. That will be a lot more common when we make Flash ask-to-activate by default in 55
* but for users who are going to need it, launching the Flash process asynchronously at Firefox startup and eagerly hooking it up to the content process would avoid this sync call and could be a nice win

Comment 4

[(no longer active)]

Note that now we have telemetry on the cost of the receiving side of the sync IPC messages (thanks to bug 1365719) so one thing that would be helpful to check is how much the telemetry for the receiving side of this corresponds to the one for the sending side, to get a rough sense whether most of the cost is in processing the sync messages or in the overhead of delivering it and waiting for the target thread to become free etc.

Comment 5

[(no longer active)]

Should we close this as WONTFIX?

Comment 6

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Yeah, marking WONTFIX. Assuming it bubbles to the top of the sync list somehow, we can maybe take a look at the ideas mentioned in Comment 3, but I'm not sure we want to make the complexity/optimization tradeoff here quite yet.