紧凑框架和 JIT。需要多长时间

Question

我们的应用程序出现了幻象延迟。这可以追溯到第一次接触对象时单例的初始化，并归咎于 JIT。我并不完全相信这一点，因为没有测量 JIT 的机制（或者有吗？）并且整个延迟是七秒。七秒 JIT？！？这可能是真的吗？

不管怎样，我很难责怪那些无法轻易衡量的事情。当我不久前看到这个问题时，我注释掉了一堆代码，并看到七秒的延迟“跳转”到应用程序的其他地方。表明它以某种方式发生在某个后台进程上（我想这会将 JIT 算作一个潜在原因）。

只是为了好玩，如果有一个静态对象碰巧引用了许多其他对象，是否有人对 JIT 可能需要多长时间有经验法则？有没有人有进一步的参考资料，以便我可以更多地了解 JIT，以便我有机会了解 JIT 是否是造成这种速度下降的原因？

Answer 1

我只见过 JIT 在一个奇怪的错误中花费了很长的时间（超过 1 秒），该错误与模板化集合中的模板化项目有关（请参阅下面的编辑）。

无论如何，你看到它“移动”的事实明确地向我表明这可能不是问题所在。为了确定这一点，我会使用 RPM 来查看延迟之前和之后发生的情况。

预期的 JIT 时间确实是一个模糊的东西，因为有很多因素会影响它。处理器速度是一个显而易见的因素，但不太明显的可能是应用程序存储介质和设备内存压力等因素。

存储介质会影响 JIT 速度，因为 JITter 在需要 JIT 时必须从介质中拉取 IL，如果拉取很慢，那么 JITting 也会很慢。

内存压力是一个严峻的问题，可能会对 CE 设备产生严重影响。这里的问题是，当你开始耗尽内存时，EE 将在收集期间开始投放 JIT 代码 - 除了调用堆栈之外的所有代码。现在，如果您处于一个例程中，例如，调用一些工作程序或帮助程序，或者有一个线程正在运行，那么该帮助程序方法可能会被调整、JITted、调整JITted等。这被称为“鞭打”。

使用 RPM 识别后者相当容易（修复它可能并不那么容易）。查看频繁提交的代码数量，并寻找提交数量的增加与您感知到的锁定之间的强相关性。

编辑： 我终于找到了 错误描述在这里.

Answer 2

JIT（和 GC）计时器等。可以在这里找到：

.NET紧凑型框架中的性能计数器（http://msdn.microsoft.com/en-us/library/ms172525.aspx)

监视 .NET Compact Framework 上的应用程序性能第 I 部分 - 启用性能计数器（http://blogs.msdn.com/davidklinems/archive/2005/10/04/476988.aspx)

使用 .Net Compact Framework 远程性能监视器分析设备应用程序性能（http://blogs.msdn.com/stevenpr/archive/2006/04/17/577636.aspx)

.NET Framework 中的性能计数器
(http://msdn.microsoft.com/en-us/library/w8f5kw2e(VS.80).aspx)

问候，坦贝格