Now that we have the protocol-as-solution functionality it's possible to put all the scripting code in just a few QActions and still maintain a readable and structured overview by making use of folders and separate cs files.
Is there negative impact when using just a few big QActions instead of many small QActions?
As every QAction actually becomes a dll in the background, your question actually boils down to: Should we go for a single large dll or multiple small ones?
There is some official documentation on this topic
It's a old article but I really recommend taking a look, it's an interesting read.
Specific to your question:
Prefer Single Large Assemblies Rather Than Multiple Smaller Assemblies
To help reduce your application's working set, you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.
The overhead associated with having multiple smaller assemblies can be attributed to the following:
- The cost of loading metadata for smaller assemblies.
- Touching various memory pages in pre-compiled images in the CLR in order to load the assembly (if it is precompiled with Ngen.exe).
- JIT compile time.
- Security checks.
Because you pay for only the memory pages your program accesses, larger assemblies provide the Native Image Generator utility (Ngen.exe) with a greater chance to optimize the native image it produces. Better layout of the image means that necessary data can be laid out more densely, which in turn means fewer overall pages are needed to do the job compared to the same code laid out in multiple assemblies.
Sometimes you cannot avoid splitting assemblies; for example, for versioning and deployment reasons. If you need to ship types separately, you may need separate assemblies.
I should note though from experience, that in general you're better off focusing on good architecture instead of efficiency and performance in this case. Use QActions as another way to separate your code for maintainability. I've seen the most success in trying to find a balance. Group together similar flows of logic in the same quickaction.
Also consider if you have to share data. Sharing it between QActions can be more difficult than having a single QAction that's 'instanced' (remove the static in the run method).
With the protocol as solution, it can still make sense to have multiple QActions to organize your features and group your triggers.
This way you can at a glance know which parameters are linked to which specific features and what they do from the protocol XML.