For our next pre-release, we did a big change. We reduced the number of plugin parts from about 500 to now about 400. About a 20% reduction. This saves us some build times. We build each plugin part for 13 targets and thus building 5200 dylib/dll/so files is better than build 6500 ones.
How did we do this?
Well, we merged over 100 plugins parts together internally. For example if you build a Windows app using our Windows USB classes, we had several plugin parts. But it is quite likely you would refercence all the parts for Windows USB if you would write such an application. Since these three plugin parts had common code, merging them reduced the size of the total code. Often merging three parts makes the resulting plugin part smaller than 2 of them.
Old size of all 52 plugins was 879 MB and now is 832 MB, a 47 MB saving. You may check if your application become bigger or smaller as your milage may vary. Due to the reduced number of plugin libraries to load, the IDE needs about 20% less time to start.
Please let us know if you find issues with your projects. Everything should just work fine like before.
I think there will be more benefits than disadvantages on what you did.
If Xojo loads faster and downloading the plugins is also smaller (albeit not much), those are 2 benefits, compared than the probable downside of a bigger app (something I’d care about less than the two benefits).
Don’t forget that you can manage your plugin sets with Plugins Pro
Part of the idea was to improve IDE loading speed by allowing you to trim down your sets to just what’s needed for any given project. You can quickly enable and disable entire sets, so one way to organize sets would be by project (unlike the screenshot which shows by vendor).
It also unzips plugins when activating them to save the IDE that step during launch.