TO DO for Performance: Why are we loading every pluggin in the pluggin directory during loading? Do we need to do this?

umm...i don't think this belongs to me. re-assigning to amusil.

This is nothing different from what 4.5 and previous browsers do when initializing plugins, and this should take no longer than a few seconds on most systems. This is currently being done in the init of LiveConnect. Patrick - can you make some comments as to what it would take to delay this action?

Reassigning Plugin bugs to Andrei

On Windows we do not load plugins in terms of LoadLibrary, but rather read plugin info from the dll's version stamps. That's needed for the plugin list initialization.

okay, i've done the stupid thing and created a directory named "plugins" in the main .exe directory for every platform. this should prevent the search for 3.0 and 4.0 plugins and prevent the spurious load attempts. there should be a second pass fix that addresses this problem in a more graceful manner.

The original report was about loading all plugins during startup, which is unnecessary on Windows. It was not like this in pre-5 world.

I moved actual dll loading to the point where it is only needed, and compared loading time in both cases in series of ten startups in each case. I tested this on 200 MHz machine with debug build and following plugins in the plugins dir: np32dsw, npaudio, npavi32, npbeatsp, npdsplay, npnul32, nppdf32, nppl3260, npqtw32, npswf32, npvcal32, npwinless. The time needed for gathering plugin info only was: when plugins loaded -- 2637 msec average with 380 msec of standard deviation, when plugins not loaded -- 379 msec average with 39 msec of standard deviation. Gain is more than two seconds with twelve plugins.

paulmac, can you mark Verified?

I will when I verify it, I promise :-)

Okay, I don't have a great way of testing this, but I see no difference in load time with or without a plug-ins directory, leading me to believe that plug-ins are not being loaded at start-up. Marking verified.