最小的跨 AppDomain 通信性能损失是多少? [英] What is the minimum Cross AppDomain communication performance penalty?

问题描述

我试图将在同一台机器上跨 AppDomains 通信的性能损失降到最低.在我的玩具示例中，类 A 被加载到 AppDomain 1 中.它创建了一个 AppDomain 2 并在那里加载了一个类 2 的实例(类 2 继承自 MarshalByRef)以获取代理.然后类 1 重复调用代理上的一个不返回值的方法.

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.

我得到以下结果:

1. 没有 AppDomains，两个类都加载在同一个 AppDomain 中，第一个类重复调用第二个上的方法(该方法没有参数):2400 万 方法调用/秒
2. 如上所述的两个 AppDomain，方法没有参数或出血"字符串参数:340.000 个方法调用/秒
3. 如上所述的两个 AppDomain，一个可序列化参数(两个字符串的数组):64.000 次方法调用/秒

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

虽然我理解 2 和 3(序列化)之间的性能损失，但我真的不明白为什么我从案例 1 到案例 2 慢了 100 倍.据我了解，一旦创建了代理，所有后续方法调用都必须非常快，因为没有数据从一个 AppDomain 编组到另一个 AppDomain.现在有人为什么跨 AppDomains 通信如此缓慢?我做错了什么吗?

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.我对此的唯一提示是此处:而跨越 AppDomain 边界的成本令人尴尬.".我猜他指的是序列化...

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.我不计算 AppDomain 或 Proxy 创建时间(我的基准测试从第一个方法调用开始)

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

PS3.我在 WinXP SP3 机器上使用 .NET 3.5.我还尝试了 .NET 4.0 Beta 1，但没有显着差异.

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

推荐答案

如果计算每个场景中涉及的 IL 行数，您会发现 CLR 在远程处理时所做的工作是 100 倍以上.直接调用只是几个操作码，但是远程处理涉及多个类、真实/透明代理、安全检查、序列化、yadda yadda yadda.您需要通过设计来解决这个问题 - 没有通过实施来提高性能的灵丹妙药.

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.

这篇关于最小的跨 AppDomain 通信性能损失是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！