由于 JIT_MethodAccessCheck，编译表达式树很慢答案

【问题标题】：Compiled Expression Tree slow due to JIT_MethodAccessCheck由于 JIT_MethodAccessCheck，编译表达式树很慢
【发布时间】：2015-04-01 17:38:35
【问题描述】：

我们使用已编译的表达式树来动态生成代码；一些仅在运行时才对我们可用的信息使我们能够（理论上）编写更简单、更快的代码。在许多情况下，我们确实获得了性能提升。

但是，在某些情况下，我们的性能会受到影响。在这种情况下，Visual Studio Profiler 显示性能差异是由于这种方法造成的（在静态编译的代码中根本不会出现）

JIT_MethodAccessCheck

这个方法有什么作用？（谷歌对此没有太多可说的）。我可以以某种方式优化它吗？

【问题讨论】：

它是一个jitter helper函数，它会自动生成一个调用来验证沙盒限制。确切的细节非常模糊，你可以通过 coreclr 源代码挖掘来找到细节。优化代码最重要的细节是知道何时完成。如果这个函数占主导地位，那么你可能已经完成了。
@Hans 是不是[assembly: AllowPartiallyTrustedCallers] [assembly: SecurityTransparent] [assembly: SecurityRules(SecurityRuleSet.Level2, SkipVerificationInFullTrust = true)]可以修复的“东西”？
@xanatos - this question 之后的 cmets 包含这些属性，因此值得一试。
我还发现了this answer，虽然它指定了不同的 clr 方法，但似乎与我的问题非常相似。
@Hans 有问题的代码在软实时系统中对性能至关重要。分析表明这个新调用需要 10 毫秒，即 6%。不是很大，但也不是微不足道的。令人担忧的是，它是与表达式树一起引入的——如果它一直在那里，我怀疑我们会不会看到它。

【解决方案1】：

JIT_MethodAccessCheck 方法执行安全检查，例如 @xanatos 提到的SecurityTransparent、APTCA 和类访问检查。

类访问检查包括SecurityCritical、SecuritySafeCritical、附加分析器绕过和LinkDemand。更多细节可以在 coreclr jithelpers.cpp 找到。

由于 coreclr 与 CLR 兼容，我们可以放心地假设两者的检查方式相同。

【讨论】：

【解决方案2】：

使用此答案中的代码 sn-p 来编译表达式树，它摆脱了跨方法边界的检查：

【讨论】：