Closed
Bug 818265
Opened 12 years ago
Closed 8 years ago
Flash NPP_Destroy takes ~90ms. Impeding shutdown, navigation.
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: BenWa, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [Snappy:P1])
Startup report:
https://people.mozilla.com/~bgirard/startup_report/report.html#PluginInstanceParent::Destroy
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?
Comment 1•12 years ago
|
||
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.
Reporter | ||
Comment 2•12 years ago
|
||
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?
Reporter | ||
Updated•12 years ago
|
Blocks: start-faster
Comment 3•12 years ago
|
||
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...
Comment 4•12 years ago
|
||
Plugin shutdown time measures https://bugzilla.mozilla.org/show_bug.cgi?id=706647
Reporter | ||
Comment 5•12 years ago
|
||
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.
Reporter | ||
Comment 6•12 years ago
|
||
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.
OS: Mac OS X → All
Hardware: x86 → All
Summary: [Shutdown] Plug-in shutdown takes ~90ms on shutdown → Flash NPP_Destroy takes ~90ms. Impeding shutdown, navigation.
Reporter | ||
Updated•12 years ago
|
No longer blocks: start-faster
Reporter | ||
Updated•12 years ago
|
Blocks: shutdown-faster
Updated•12 years ago
|
Whiteboard: [Snappy:P1]
Comment 7•8 years ago
|
||
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•