I have the full MBS plugin suite and a couple my own custom ones. I could understand if xojo took some time the first time around with a new set of plugins (decompress them, etc, etc and write what it needs to cache on a given machine). But waiting 20 min every time?
The problem is compounded when you write your own plugins: with each iteration, you need to quit xojo and relaunch to reload your new plugin…then wait another 20 min. Am I missing some pref or setting or is this the new norm? What’s it doing at every launch that takes so long?
I noticed that when I upgraded to Catalina. I might be wrong but it is possible that the slowest is not cause on XOJO end but rather the Gatekeeper checking every single plugins each time you launch Xojo.
That is a good point, and what I used to do with RS. I figured xojo would be optimized and would decompress/cache the plugins just once, and intelligently detect new ones for caching. I guess I was wrong. The thing with MBS is figuring out dependencies is not always intuitive.
If I’m not doing anything obviously silly that would cause this slowdown, then pruning is the only option.
Which is a painful and unreliable way to do it, since before you even begin working through that list, you need to look at all the MBS calls you make in your project and try to work out which plugins they come from!
I usually look in the libs folder of my Windows build to see what is actually ‘needed’.
(Although why I get dlls and libs which refer to Apple systems, in a Windows build, frustrates me.)
The problem is that Xojo doesn’t use plugins (except for the few DB plugins) and therefor doesn’t see the pain many of their users go through with the very slow startup and plugin compile times. It would be great if they practiced what they preach and spawn helper processes to load and compile plugins.
I would think it would be nice if xojo could generate a preferences file in the plugins folder that contained what plugins were used in the given project so after the first compile only those plugins would load. If you needed to add a plugin you could edit the prefs file.
[quote=467917:@Bob Keeney]The problem is that Xojo doesn’t use plugins (except for the few DB plugins) and therefor doesn’t see the pain many of their users go through with the very slow startup and plugin compile times. It would be great if they practiced what they preach and spawn helper processes to load and compile plugins.
Anyone have a Feedback report that asks for this?[/quote]
At some time in the past I ran instruments on Xojo to see what it was doing during startup. From what I saw I got the impression the bottleneck while loading plugins was doing stuff the IDE needed (maybe for auto-complete) rather than actually loading the plugin’s executable code. I don’t think helper processes would help there but maybe caching of the data in a SQLite database would.
Faster precompiling of plugins would be most appreciated as compiling all 3 targets for the first time after a plugin change is basically a toilet & tea break.
I did timings on my MBP 2013 running macOS Mojave before I moved to my shiny new MBP 16", sadly running Catalina. All timings were faster (not by as much as you’d think or hope) on the 16" MBP, except for the startup, which was three times as long. I’m pretty sure NannyOS is phoning the mothership for each plugin to make sure Tim Cook approves its use.