This currently list 10 shutdown profiles sorted from longest to shortest time spent in PluginInstanceParent::Destroy recorded on my system. Click on the profile will preview the profile + highlight the function.
Filing this bug even if I'm not sure if there's a ton we can do without a NPAPI change. Any ideas Benjamin?
We could TerminateProcess the plugin-container. I don't know whether that would totally destroy Flash data structures. Other than that, don't expect magic bullets.
TerminateProcess? Do you just mean kill the plugin process?
Would it be possible to shutdown the plugin process async and have any other NPAPI call fail?
Yes, I mean killing the plugin process. It would be very difficult to asynchronously shut down the plugin process because it almost certainly continues to make calls into the browser as part of shutdown, and those would all need to be stubbed out with some kind of error message (and those error might cause additional instability). I think that if we're going to experiement with this, terminating the process is the better choice.
We could ask Adobe whether we they provide a new "shutting down now" API which would immediately save persistent state and then allow us to terminate the process more safely...
Plugin shutdown time measures https://bugzilla.mozilla.org/show_bug.cgi?id=706647
Note that this measurement is very different then what my profile is measuring. It appears that we spend a lot of time destroying plugin instances on shutdown not the plugin process.
I did more research on this. I can reproduce this on a fast windows machine as well as on mac. I confirmed that the slow down was coming from NPP_Destroy. Skipping that call makes the problem go away but will leak resources and will not let the plugin persist data. Leaking resource is okay on an optimized shutdown but we still need to persist data. This problem is particularly bad on shutdown because it scaled linearly with the number of open tab. i.e. 10 youtube tabs means you've added 1 second to your shutdown time.