I have a project that typically takes 1.5 minutes to load. I was a bit surprised that this hadn’t changed on my new MacBook Pro since it uses a pure SSD instead of the Fusion drive of the iMac, so I did some experimenting. I removed all but the default plugins and one other from my Plugins folder, cleared the cache, and tried again. Now it takes about 38 seconds to load the same project.
Is anyone else surprised that plugins make a difference here?
I’m not really surprised. Plugins have always slowed down the Xojo load time for me and I’ve used it on (not to tout anything) a wide range of Macs. I had considered writing a plugin / project manager, but after the announcements at XDC the idea got pushed really, really far down. I’d like to see what they come up with first.
did you have a lot of plugins, or only some ?
anyway this only conforts me in my anti-plugin policy !
I disabled 65 plugins, which seems like a lot. Is that a lot?
I know people who have a lot of plugins.
But normally you can reduce to those you really use.
e.g. typical user only needs 10 to 20 MBS Plugins.
Not in the least
Try loading the project with only the basic plugins that come with Xojo. It makes a HUGE difference. Unless my current project requires plugins, I usually never keep any additional ones.
it makes an ENORMOUS amount of difference
I have a sample project that takes about 15 minutes to load and about 40 minutes to resolves the 50,000 or so issues it has (deliberately)
With more than just the basic DB plugins these times grow like mad (its not exponential but it sometimes feels like it)
Remove them and its back to a “speedy” 15 minutes to load 
How do you work out which plugins are in use, other than trial and error?
I find that the dylibs that are saved with the app dont have the same names as the plugins they come from.
eg MBS_FolderItem_Plugin_18844.dylib is saved into the compiled app, but there is no plugin of that name…
the MBS Plugin parts are listed here:
http://www.monkeybreadsoftware.net/partsall.shtml
FolderItem is a part of Util plugin.
Thanks.
So write down the dylib names, then use this webpage to work out what to include?
Shame there is nothing automated…
Well, let me check if I can simply include the plugin name in that dylib name.
here are some plugins:
https://www.dropbox.com/s/sqobgfopau9ms8i/Xojo%20Plugins.zip?dl=0
Does that help?
[quote=307278:@Jeff Tullin]How do you work out which plugins are in use, other than trial and error?
I find that the dylibs that are saved with the app dont have the same names as the plugins they come from.
eg MBS_FolderItem_Plugin_18844.dylib is saved into the compiled app, but there is no plugin of that name…[/quote]
In use depends on the project thats open & the code in it
And as soon as you open a different project the “required set” might change
I think there’s a feature request for the IDE to show “dependencies” like this (dont know the # off the top of my head)
There is also an announced feature for plugins to be stored with projects, which will help a lot.
1.5 minutes is surprising, but…
.< Are we joking here? What could it be doing that possibly takes 15 minutes?
Yup, still 2017, and not April 1st
Theres a feature to make it possible for plugins to be made with Xojo and those plugins can be per project.
This will have no effect on MBS, Einhugur, etc
Well shuuuute. We were kind of all expecting hoping it would apply to the MBS, Einhugur, etc plugins too.
Not joking
1500 windows - many of these windows have in excess of 1000 controls
1500 menu bars
1500 container controls - many of these have in excess of 1000 controls
1500 modules that each contain about 1000 classes
Its a stress tester for the IDE so I can profile something that REALLY takes a long time to load
Running the ide in debug mode with profiling on this particular project sometimes exceeds an hour to load
Never mind fixing the issues 
Not today, but it might one day. I wouldn’t be too surprised to find in the future that the new Xojo-based plugin format is moving along and existing plugin authors end up wrapping and shipping some of their plugins that way for those future versions of Xojo (since they can still call C libs, etc). But that’s something none of us- including the plugin authors- can really predict at this point.