Closed
Bug 506472
Opened 14 years ago
Closed 2 years ago
nsPlugArray::Refresh -> nsPluginHost::ReloadPlugins takes large chunk of time at startup
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: vlad, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [ts])
On OSX, nsPluginArray::Refresh (which calls nsPluginHost::ReloadPlugins) takes a large chunk of time, easily up to 1s on a cold start. It seems to trawl through plists and otherwise do a pile of IO. Is there any way we can delay figuring out plugin availability and all that until we actually need the info? (Either to instantiate a plugin, or to show about:plugins or the plugins addons mgr page.)
Reporter | ||
Updated•14 years ago
|
Whiteboard: [ts]
Reporter | ||
Comment 1•14 years ago
|
||
This is probably likely related to bug 492621 which was sort-of fixed.
![]() |
||
Comment 2•14 years ago
|
||
What's the stack to that call? Is this us trying to get the MIME type for a nsFileChannel when we don't have a type mapping for the extension?
Comment 3•14 years ago
|
||
joel, vlad said this is super expensive on mac - can you take a look?
Reporter | ||
Comment 4•14 years ago
|
||
Cc'ing the right joelr :)
Comment 5•14 years ago
|
||
What is the stack to that call? A breakpoint on it didn't trigger on either startup or when I watched some Flash videos. I manually triggered it via javascript:navigator.plugins.refresh(true) after sync && purge and found the plist I/O mentioned, which took nearly 0.5s. Here's the data I captured. All of this I/O is done in nsPluginArray::Refresh and the stack below it after that manual trigger. http://people.mozilla.com/~adw/startup/data/10-22/nsPluginArray-01
Comment 6•14 years ago
|
||
Apologies to people who know this code. I spent most of the day spelunking through mxr trying to find where this might be called on startup, without much success. Most of the work is done in nsPluginHost::ScanPluginsDirectory. Plugins are actually loaded from nsPluginFile::LoadPlugin. Startup doesn't trigger a breakpoint on LoadPlugin though. Given comment 0, it seems to be conditional then (or maybe fixed since). That jibes with the logs of files I've been generating while working on Ts, since the plists, etc. don't show up in them. I looked for callers in mxr, which is fun since someone might be calling anything from nsPluginFile::LoadPlugin to nsPluginArray::Refresh and all functions in between. Wasn't able to look through everything, but I didn't find any potential startup callers except safe mode, the blocklist service (but that's on a timer), and channel code that needs to get mimetypes, as bz mentioned. The mimetype stuff is the most likely culprit? I could use dehydra to get a better view. Vlad, anything noteworthy about your profile that might help?
Comment 7•2 years ago
|
||
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Updated•1 year ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•