C# – the minimum Cross AppDomain communication performance penalty

appdomaincperformance

I am trying to minimize the performance penalty of communicating across AppDomains in the same machine. In my toy example, Class A is loaded in AppDomain 1. It creates an AppDomain 2 and loads there an instance of Class 2 (Class 2 inherits from MarshalByRef) getting back a proxy. Then Class 1 calls repeatedly a method on the proxy that returns no values.

I get the following results:

  1. No AppDomains, both classes are loaded in the same AppDomain and the first calls repetedly the method on the second (the method has no parameters): 24 million method calls/sec
  2. Two AppDomain as described above, method has no parameters or "bleeding" string parameters: 340.000 methods calls/sec
  3. Two AppDomains as described above, one serializable parameter (array of two strings): 64.000 method calls/sec

Although I understand the performance penalty between 2 and 3 (serialization), I really don't understand why I am 100 times slower from case 1 to case 2. To my understanding, once the proxy is created all subsequent method invocations must be really fast since no data are being marshalled from one AppDomain to the other. Does anybody now why communicating across AppDomains is so slow? Am I doing something wrong?

PS1. The only tip that I have on this is here: "And the cost of crossing an AppDomain boundary is embarrassing.". I was guessing he refers to serialization…

PS2. I don't count the AppDomain or Proxy creation time (my benchmarks start in the first method invocation)

PS3. I am using .NET 3.5 in a WinXP SP3 machine. I also tried .NET 4.0 Beta 1 with no significant differences.

Best Answer

If you count lines of IL involved in each scenario, you will see that the CLR is doing much more than 100 times the work when remoting. A direct invocation is just a few opcodes, but with remoting there are multiple classes involved, real/transparent proxies, security checks, serialization, yadda yadda yadda. You will need to address this through design - there is no magic bullet for improving perf through implementation.