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

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.)

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This is probably likely related to bug 492621 which was sort-of fixed.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

[Dietrich Ayala (:dietrich)]

joel, vlad said this is super expensive on mac - can you take a look?

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Cc'ing the right joelr :)

Comment 5

[Drew Willcoxon :adw]

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

[Drew Willcoxon :adw]

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

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.