.net 通过COM的Assembly.GetTypes在System.Data.Entity上花费很长时间

我发现一个方法存在性能问题，该方法定位从某个类型派生的类型。它使用反射获取当前加载的所有程序集（

AppDomain.CurrentDomain.GetAssemblys（）

），然后迭代每个程序集中的所有类型（

assembly.GetTypes（）

）以查找匹配项。它在一个单独的DLL中实现，可以在.NET应用程序中使用，但它也是COM可见的，可以从VB6应用程序中调用

这种方法非常有效，在许多情况下也表现良好。我的问题是，在某些情况下，对assembly System.Data.Entity的GetTypes调用需要很长时间，超过5秒。以下是主要观察结果：

• GetTypes调用总是花费很长时间的System.Data.Entity，而不是另一个程序集。在50个其他加载的程序集上可能会有GetTypes调用，但所有这些调用都会立即完成
• 如果从.NET应用程序（例如.NET控制台应用程序）中调用该方法，则不会出现此性能问题。GetTypes调用总是在瞬间完成
• 如果该方法是从通过COM使用my DLL的VB6应用程序中调用的，则问题经常发生，但并非总是如此。我还不知道，是什么原因导致5秒以上的时间延迟有时发生，有时不发生

我已经用最少的测试应用程序成功地验证了上述观察结果，因此没有什么比我刚才提到的更重要的了

我不知道是什么导致了这个问题。有人有主意吗

问候,，

---

彼得。

这听起来不像是一个.NET冷启动问题。是的，加载CLR、查找磁盘上的所有程序集、及时编译所有代码需要一段时间。@Hans，谢谢您的回复！我看到调试器在执行.NET代码时出现延迟，因此这与加载CLR无关。另外，由于

AppDomain.CurrentDomain.getAssemblys（）

迭代所有加载的（！）程序集（至少是这样说的），因此它似乎也不涉及加载任何DLL。最后，我不知道应该为另一个调用

Assembly.GetTypes

对另一个程序集进行JIT编译的代码。根据您提供的信息，这是无法诊断的。您需要收集更多数据，请使用托管探查器。