The clean soultion is not to load the library on startup, if the plugin is disabled and if possible unload it, if it gets disabled on runtime.
I was wondering what the "attach/detach" scheme is for. Is it for cases where one library provides several plugins and you only want to activate (attach) one of the plugins?
I don't see that loading the library or looking up functions in them consumes the time. It is the calls to Manager::LoadResource(...) that take half a second on my system. I haven't looked any further though. Maybe it is wxWidgets XML resources inside the zip files that take long to parse, maybe not. The plugin system is working and many people have contributed. Wouldn't it be best to try and set up a second plugin loader that uses the existing IDE integration stuff, but a different interface to the plugin libraries? Maybe the library could provide the metadata itself and the zip remains untouched until you try and activate the plugin.
On a different note oprofile shows a high sample count inside of wxString and tokenizer methods during the loading of the IDE. I think I'll look some more at what is actually causing the major slowdowns of 400ms and more for me. Even if that doesn't yield a fix it is always nice to know what functionality is slow on what system.
EDIT: I have nailed it down to "wxXmlResource::Get()->Load(memoryFile);"
memoryFile is string instructing wxWidgets to load all wxXmlResource files from the named memory location (where a zip file's data has been loaded to). This is beautiful, because it is really simple and straight forward. The method decompresses the zip data, scans the directory index for .xrc files and parses them all at once. The only downside is that it takes its time
. At least wxGTK-2.8.10.1 is.
EDIT2: Under Windows Vista there is no problem with loading the plugins like that. I'll try disabling compositing under Linux next...
EDIT3: Disabling compositing didn't change anything.
