It would be great to have profiles for Plug-ins’ Enabled/Disabled status (e.g. “Profile1”, …) and then be able to use startup flags (like “…\Rhino.exe /Profile1”) to start Rhino with one of those profiles. It would be great to have this functionality for both Rhino and GH plug-ins.
Reason for this wish is: By now Rhino can become pretty plug-in heavy and we usually only require a subset of plug-ins to be running at one time. The effect on performance and stability is manifold:
Slow startup times, due to some plug-ins connecting to servers (presumably).
Slow startup times just due to the amount of plug-ins to be loaded.
Slowed down performance of Rhino/GH: Many plugins register callbacks that can severely slow down Rhino. For example, we use VisualArq. When Tibidao is loaded, slicing of a heavy example brep with planes in GH takes around 30 minutes, with Tibidao disable the exact same brep and GH definition takes around 40 seconds.
Crashes due to errors in callbacks, even if functionality of the plug-in is not used.
Unnecessary and just annoying functionality, like drawing stuff over the viewport.
As a temporary solution you could write a Powershell or Batch script, copying and pasting plugins on demand. You could misuse the ability to setup custom include folders in the Grasshopper Dev settings or you could write a plugin, acting as a middleware to dynamically load plugin assemblies from different locations.
However in the end you need to be very careful with which plugins to install. In most of my professional work I was never in need for more than 3 plugins. It is very important to reduce dependencies, for many different reasons. Remember most plugins are contributions with zero warranty. Also, you shouldn’t trust any plugin, nor you should thrust Food4Rhino scanning them properly! What you encounter as a stability or performance issue, can be something worse!
Btw, unloading assemblies was a big problem in times of .Net Framework, and partially it is still a problem. There are still unresolved issues with using the AssemblyLoadContext and a WPF application. Plugin architecture is a problem for this tech stack. Best solution is still to never unload assemblies.
@TomTom Thanks for raising awareness for malicious actors. Just read your other post about this. I might want to be more careful with plugins connecting to unknown servers.
Btw. have we met at Andrea’s workshop with the wax robots quite some years ago?
