What is the overhead of using SLProtocolExt instead of SLProtocol? Since SLProtocolExt is superset of SLProtocol, object of type ConcreteSLProtocolExt is naturally larger then ConcreteSLProtocol. How big of an performance impact is this and what are the cases where this overhead needs to be considered?
Once decision is made to use SLProtocolExt instead of SLProtocol, does number of QActions that use SLProtocolExt matter, or does every QAction use the same instance of ConcreteSLProtocolExt, which gets instantiated on the call to the first QAction that needs it? More generally does new ConcreteSLProtocol object get instantiated for every call to QAction?
The overhead of SLProtocolExt is that all parameter types are added on the memory heap, these need to be constructed first, and for somebody that needs to debug an SLScripting memory dump it will be harder for them to dig through all the items: imagine if a protocol.xml has 5000 parameters that somebody that is checking the heap sees these 5000 items next to the basic types like string, int,...
Every QAction has their own SLProtocol object, this is not shared. A perfect example of this is the protocol.GetTriggerParameter() call, when all QActions would be using the same SLProtocol object then the result of this call would be the same for every QAction. Further, a new SLProtocol object gets instantiated at every QAction run.
To summarize: using SLProtocol over SLProtocolExt is preferred, specially when the SLProtocolExt members are not being used, as SLProtocol is faster to load when starting a QAction and will not take up as much space on the heap in memory.[Edit]: summary after taking a deeper look (see comments):
SLProtocolExt is a 'relatively' small performance hit in most cases and its fine to use if it's for readability and you actually use its features.
So if using the SLProtocolExt functionality is preferred then feel free to do so, but it’s a pity to define SLProtocolExt and then only use a basic GetParameter or SetParameter call that an SLProtocol object also offers. Executing one protocol.SetParameters call is also still preferred over multiple protocol.SetParameter calls, which does not happen when assigning values to single parameters when using SLProtocolExt.
Hi Edib. As Laurens already mentioned, there could be a small performance impact when using SLProtocolExt, because some objects are being allocated. However the impact is probably very small and will almost never be a problem in practice. Personally I prefer more readable code over such micro-optimizations. When performance becomes a problem there are most likely other things that can be improved that will have a much bigger impact. I always use SLProtocolExt, and as far as I'm aware it has never caused problems.