31

我的团队使用大型模拟应用程序的 COM API。大多数模拟文件运行到数百兆字节，并且在打开时似乎完全加载到内存中。

我们执行的主要任务是遍历文件对象模型中的所有元素，然后对每个元素执行“某些操作”。

我们最近在 VS 2010 中将代码库从 .NET 2 迁移到了 .NET 4，并且看到迭代速度下降了大约 40 倍（从大约 10 秒到大约 8 分钟）。我们已将其简化为尽可能小的代码示例（10 行左右）；在 VS 2005 中编译它，运行它，然后在 VS 2010 中打开项目并编译，将框架保留为 2（我们使用制造商提供的 COM 互操作程序集）。

2005 年测试应用程序在 10 秒内完成，而 2010 年则需要 8 分钟。

这可能是什么原因造成的？

更新

代码等价于：

var server = new Server();
var elements = server.Elements;
var elementCount = elements.Count;

for(int i = 0; i < elementsCount; ++i)
{
    var element = elements[i];
}

这段代码在 VS 2010 中运行所需的时间是 VS 2005 的 40 倍。

更新 2

我合理地解释说，在一种情况下操作可能比另一种情况慢得多的唯一原因是数据在不同版本中通过 COM 传输的方式不同。

我们记录了这两种情况的绑定日志，这就是我们发现的；在快速版本中找不到 CustomMarshalers 的原生镜像（这些是 FUSLOGVW 捕获的绑定日志）

mscorlib

mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.HTM

快速地

LOG: Start binding of native image mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: Start validating native image mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
WRN: Native image does not satisfy request. Looking for next native image.
WRN: No matching native image found.

慢的

LOG: Start binding of native image mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: Start validating native image mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: Bind to native image succeeded.

自定义封送器

CustomMarshalers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

快速地

LOG: Start binding of native image CustomMarshalers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Start validating native image CustomMarshalers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
WRN: Native image does not satisfy request. Looking for next native image.
WRN: No matching native image found.

慢的

LOG: Start binding of native image CustomMarshalers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Start validating native image CustomMarshalers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Start validating all the dependencies.
LOG: [Level 1]Start validating native image dependency mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
LOG: Dependency evaluation succeeded.
LOG: [Level 1]Start validating IL dependency Microsoft.VisualC, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
LOG: Dependency evaluation succeeded.
LOG: Validation of dependencies succeeded.
LOG: Start loading all the dependencies into load context.
LOG: Loading of dependencies succeeded.
LOG: Bind to native image succeeded.
Native image has correct version information.
Attempting to use native image C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\CustomMarshalers\3e6deccf191ab943d3a0812a38ab5c97\CustomMarshalers.ni.dll.
Native image successfully used.

因此，当不使用本机图像时，我们似乎获得了很大的性能提升。

为什么这种绑定在一种情况下会失败而在另一种情况下会成功，我们如何强制应用程序不使用本机映像？

更新 3

怪事还在继续。如果我在 VS 2010 中使用 R# 测试运行器或内置的 Visual Studio 测试运行器在测试方法中运行此代码，那么它运行速度很快。

我曾尝试将此代码包装在一个程序集中，然后动态加载它，这没有任何区别。

4

2 回答 2

6

这是一个很长的镜头。很高兴我能帮上忙。

在对任何 COM 对象进行大量不同调用时，匹配 MTA 与 STA（线程模型）非常重要。[STAThread]方法顶部的指令是确保该方法中每个调用的线程模型的一种方法 。

看起来Thread.SetApartmentState(ApartmentState.STA)适用于整个线程，但显然不适用于线程池线程。

于 2012-10-10T13:29:39.177 回答
2

当您说“……即使在 STA 应用程序中，线程也是……”时，这实际上是不正确的。线程可以选择在访问任何 COM 对象之前设置其单元状态，但在 .NET 中，如果您什么都不做，这些线程将隐含地成为 MTA。

线程池是 MTA。如果您考虑一下，就必须如此，因为如果它充满了 STA 线程，那将是一个糟糕的线程池，因为任何时候线程尝试访问在池中的其他线程之一上创建的对象时都需要编组。

Thread.SetApartmentState 根据定义仅适用于每个线程。它永远不会影响任何其他线程（正如您所发现的）。对象属于一个单元，一个线程可能属于一个单线程模型。如果线程试图访问模型不匹配的对象，则需要对其进行编组。

如果您的 COM 服务器被标记为“两者”，那么您可以在没有来自 STA 或 MTA 线程的代理的情况下使用它。如果是这种情况，那么您很幸运，您应该首先在 MTA 线程上创建它（或者让线程池线程这样做）。

如果您在 STA 线程上创建它，即使（特别是如果）所有其他线程都是 STA，它们都将通过代理，除非您碰巧从最初创建它的线程调用该对象。

如果您的 COM 服务器是单线程的，那么您需要确保不仅从 STA 线程调用它，而且从首先创建它的 STA 线程调用它，否则您将通过代理进行编组。

于 2012-10-10T15:27:57.597 回答