Performance of System.AddIn

Jan 22, 2008 at 3:02 PM
I have one scenario where I'm using System.AddIn now, and I'm trying to determine where else I want to stick it in.

To do that, I need more of a clue than I have on the performance issues.

The AppDomain stuff would be a very nice to have, but is not required in these scenarios.

Is there a blog entry, or can someone comment here on the performance implications of using System.AddIn vs. a factory method and loading assemblies into the same AppDomain on the fly.

If I make extensive use of AppDomains I'll be loading less than a dozen but calling them many thousands of times. I am not worried about the AppDomain load time much, but am wondering about the cross AppDomain calls. Do these take a handful of milliseconds more than the in domain. On the order of a millisecond per call is not a problem. On the order of a tenth of a second is starting to be a problem.

If it matters, I'll be passing enums and possibly return structures.

So, I know firm numbers are impossible to ascertain, but what sense of performance can I get?
Jan 23, 2008 at 5:08 PM
There is actually a very wide variation in the performance characteristics of communication across the AppDomain boundary depending on your object model and a few other factors. A more in depth discussion/article would definitely be worth while but I think give you a rough idea of what to expect here.

First off the perf goals of System.AddIn were always that we should add no noticable cost to the cost of crossing and AppDomain or Process boundary and to make sure that we do everything we can to allow you to take advantage of the best perf scenarios for doing so. We have suceeded in this front and so the cost of crossing an isolation boundary using System.AddIn is not measurably different than doing so without. However, it does add the AppDomain cost.

To give you a point of reference: on my main machine (middle of the road box with lots of other stuff running) running a small test app built in release mode and without a debugger attached :

For calls that only take/return serializable types I get (by default) between 4000 and 9000 calls per second crossing an AppDomain boundary.
For a call that takes in a single IContract returns void gets about 3000 calls per second.
For a call that takes in a single IConrtact and returns a single IContract it is about 1300 calls per second.
For a call that takes in two IContracts and returns a single IContract it is about 600 calls per second.

So for the above common uses the worst case on this box is a little less than 2ms per call. If most of your calls involve serializable types rather than passing around other IContracts then you should see much better numbers than even that.

I'll go into more details about why another time, but for calls that only take/return serializable types you can get dramatic improvments by installing your contract assembly into the gac and turning on sharing between AppDomains: for the same scenarios above that yielded 4000-9000 calls per second, this optimization made the number jump to between 90,000 and 220,000.

--Jesse
Feb 1, 2008 at 10:06 AM
Edited Feb 4, 2008 at 1:21 PM
Thanks Jesse for your answer, I was about to ask the same question as Kathleen. I am very interested in any further article about performance.

I have noticed that in the online version of MSDN, there is a page about Addin performance, here : http://msdn2.microsoft.com/en-us/library/bb892925.aspx This page seems to be quite recent, because it is not in the MSDN library I have installed with VS2008.

About AddInToken.EnableDirectConnect, this flag makes the calls in-process AND without adapter instantiation. It would be great to also have a flag for in-process calls WITH adapter instatiation !

Host-side adapters are not used in any of the samples you provide. Guess what ? I would like to choose whether I want to use host-side adapter, and/or add-in side adapter, and/or use plug-ins in the same app-domain as the host or not...

--Pierre