614423 - Meta: Reduce plugin-enumeration IO

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[(dormant account)]

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

Comment 1

[(dormant account)]

Attachment: log

Note, this user only has the flash plugin enabled

Comment 2

[(dormant account)]

bug 613679 fixed this too.

Comment 3

[(dormant account)]

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

Comment 4

[(dormant account)]

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 :(

Comment 5

[(dormant account)]

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.

Comment 6

[(not currently active) Ted Mielczarek]

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

Comment 7

[(dormant account)]

(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 :)

Comment 8

[(dormant account)]

Attachment: this cuts down the number of firefox stat() calls by 4x

Comment 9

[(dormant account)]

(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

Comment 10

[Damon Sicore (:damons)]

blocking final.

Comment 11

[Benjamin Smedberg]

Taras, is this done?

Comment 12

[(dormant account)]

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

Comment 13

[Dave Garrett]

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

Comment 14

[(dormant account)]

(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

Comment 15

[Tomas]

Then time to land this?

Comment 16

[(dormant account)]

(In reply to comment #15)
> Then time to land this?

Everything is landed, this is just a tracking bug

Comment 17

[Florian Quèze [:florian]]

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.