Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Jenna on February 07, 2011, 09:36:09 am
-
C::B ships with many plugins, but not all users need all of them.
At the moment the user can disable them via the "Plugin" menu.
But the plugins will still be loaded and this seems to increase the load-time on some systems.
The only solution to prevent plugins from loading is to delete (or rename) the according library.
I just added debconf-scripts that let the user decide, which plugins should be loaded on start.
I do this by renaming the (unchecked) libs to *.do_not_load in the postinst-script, so they can be reenabled at any ty by simply running "dpkg-reconfigure codeblocks" or "dpkg-reconfigure codeblocks-contrib".
-
The only solution to prevent plugins from loading is to delete (or rename) the according library.
Replace 'The only' with 'The easiest'.
The current plugin loading code/scheme is wrong/broken, but I'm sure no one is going fix it...
-
The only solution to prevent plugins from loading is to delete (or rename) the according library.
we can create an "allow plugin list", so we only load these plugins.
BTW:
it was really annoying when debugging C::B with a lot of plugins under windows. the load time of gdb will be really slow.
-
The only solution to prevent plugins from loading is to delete (or rename) the according library.
Replace 'The only' with 'The easiest'.
The current plugin loading code/scheme is wrong/broken, but I'm sure no one is going fix it...
Maybe some day, if someone (me ?) finds the time.
At the moment there is another (most likely more important) issue to look into:
If compiler-library is removed, you can not open any files with "File->Open" or from recent file list, because C::B crashes immediately.
That's the cause, why I inhibit renaming of compiler pluzgin via debconf.
The only solution to prevent plugins from loading is to delete (or rename) the according library.
we can create an "allow plugin list", so we only load these plugins.
BTW:
it was really annoying when debugging C::B with a lot of plugins under windows. the load time of gdb will be really slow.
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.
-
@jens
several days ago, I used to change the code to let some plugin(only) loaded.
see here:
http://forums.codeblocks.org/index.php/topic,12951.msg87301.html#msg87301
-
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.