Closed Bug 506472 Opened 15 years ago Closed 3 years ago

nsPlugArray::Refresh -> nsPluginHost::ReloadPlugins takes large chunk of time at startup

Categories

(Core Graveyard :: Plug-ins, defect)

x86
macOS
defect
Not set
normal

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.)
This is probably likely related to bug 492621 which was sort-of fixed.
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?
joel, vlad said this is super expensive on mac - can you take a look?
Cc'ing the right joelr :)
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
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?
Blocks: 447581
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.