Performance and Design

We are rockin and rollin wity our VSTA-enabled apps and have come across a pivotal design question regarding the Pipeline.

The basic decision is whether to expose data as properties in the Host Item, or pass the data as a parameter to an event in the AddIn.

What is the rule of thumb when trying to decide whether to pass a bunch of data in an event vs. making a bunch of little calls to Host Item Properties to get data?

Bring it!

Event design sets some groundwork for 'rule of thumb'.

Assuming that you are assisting the programmer during an event, the best practice would rather include useful (event-related) data in an event-specific eventarg then leave it out.  The exception is if the 'bunch of data' is from specific OM objects and/or properties commonly used by the script writer in general -- then you'll have to predict what is most helpful to the end user to include in the eventarg and what to leave out. 

There is not much written down out there in this category, but with VBA Object Models, rich eventing and event parameters was the best practice. 

Hope this helps!

 

Terry,
Also keep in mind that there is a limit of four parameters for delegates- 5 or more will cause run time errors.

From the SDK section "Proxies for Managed Assemblies"

Delegates

Note:

Visual Studio Tools for Applications does not support delegates that have more than four parameters. If your object model includes public delegates with more than four parameters, ProxyGen.exe will generate proxies for these delegates. However, a NotSupportedException will be thrown when an add-in tries to use one of them.

 

>The basic decision is whether to expose data as properties in the Host Item, or pass the data as a parameter to an event in the AddIn.

This line makes us wonder if  you are thinking of passing data parameters individually, as event parameters,  rather than as properties in an event arg

 

For existing COM OMs, the number of arguments in event handlers is arbitrary and that is where this proxygen delegate parameter limitation that Melody mentioned typically comes into play.

 

So to be clear:

For events in your .Net object model, you will likely follow the .NET event delegate/handler guidelines:

• The return type is Void.

• The first parameter is named sender and is of type Object. This is the object that raised the event.

• The second parameter is named e and is of type EventArgs or a derived class of EventArgs.This is the event-specific data.

• The method takes exactly two parameters.

 

Basically, yes.  We have a "large" object that represents a line item on an order.  For us, that's a single product we manufacture (Window or Door).  This object has all the data we know about the Order Header and the Line Item, including a few hundred properties that describe the Window.

The user will need to evaluate these pieces of information to determine, or example, how to price the product based on it's size, upgrades, special features, etc.

So, we are trying to decide if we should pass the entire object as that second parameter, OR expose all of it's data as properties in the Host Item.

To me the decision is one of pipeline performance.  For example, iIf the user is going to read 10 - 20 strings from this object, is it better to pass the entire thing through the pipeline once as an event parameter, or have 10-20 calls back to the Host Item to get them.

 

 

There's less code execution overhead passing a single, dedicated eventarg type with 20 strings, by value.  Than the overhead (proxy type/host type mapping) of 20 reads on OM properties.  We have no testing or metrics to confirm this quantitatively.

But it sounds like 'hundreds' of properties in the eventarg object would need to be serialized and only a fraction (10-20) of them will actually be read by code in the the add-in's event handler.   So it would be best to test both ways with a reasonable usage scenario, if pipeline performance is an issue. 

-G