nsPluginHost::ScanPluginsDirectory takes ~4 seconds on startup enumerating directories containing disabled plugins. From xperf logs, those dlls are being loaded, so I'm guessing that ScanPluginsDirectory is unintentially LoadLibrary()ing those dlls(and their dependencies).

Note, this user only has the flash plugin enabled

bug 613679 fixed this too.

Nevermind, bug 613679 made this go away on my system, Kurt's machine is still suffering.

The problem is that nsPluginsDir::IsPluginFile check calls CanLoadPlugin() which opens files to check if they are actually plugins. I think we can all agree that memory mapping + reading a few bits of every damn dll in every a plugin directory on every startup is stupid. This is resulting in extra 30s of startup for some users :(

The files that do not get opened get stat()ed. In a sample log i got 21pointless open()s and >200 pointless stat() calls of this variety.

I assume that we do this so that we don't report that a plugin is usable if we're running as a different architecture (like our 64-bit Windows builds running on a system with 32-bit plugins installed).

(In reply to comment #6) > I assume that we do this so that we don't report that a plugin is usable if > we're running as a different architecture (like our 64-bit Windows builds > running on a system with 32-bit plugins installed). Can we not do that when we actually try to load the plugin for the first time, instead of every time :)

(In reply to comment #8) > Created attachment 494099 [details] [diff] [review] > this cuts down the number of firefox stat() calls by 4x This patch + removing .dll-reading code speeds up the enumeration process by ~4x

blocking final.

Taras, is this done?

(In reply to comment #11) > Taras, is this done? There are a few minor issues remaining: I need to track down why the java plugin is being poked on every startup and make sure that linux/mac codepaths are also fixed.

Windows and Mac seem to be dealt with now. Is there anything more for Linux that is needed still?

(In reply to comment #13) > Windows and Mac seem to be dealt with now. Is there anything more for Linux > that is needed still? Linux is ok =D

Then time to land this?

(In reply to comment #15) > Then time to land this? Everything is landed, this is just a tracking bug

Resolving this old meta bug as fixed, as all its dependencies are resolved. fwiw, there's still main thread IO related to plugin enumeration, but it's mostly due to checking the blocklist, and we are tracking fixing this up in bug 1425602.