我们的应用程序有/有一个幻影延迟。这可以追溯到第一次触摸对象时对单例的初始化，并归咎于 JIT。我并不完全相信这一点，因为没有测量 JIT 的机制（或者有吗？），整个延迟是 7 秒。七秒的JIT？！？那会是真实的吗？
无论哪种方式，我都很难责怪那些无法轻易衡量的事情。不久前，当我看到这个问题时，我注释掉了一堆代码，并在应用程序的其他地方看到了 7 秒的延迟“跳跃”。暗示它以某种方式发生在某处的后台进程中（我猜这会将 JIT 视为潜在原因）。
如果有一个碰巧引用了许多其他对象的静态对象只是为了好玩，是否有人对 JIT 可能需要多长时间有一个经验法则？有没有人有进一步的参考，所以我可以了解更多关于 JIT 的信息，这样我就有机会了解 JIT 是否应该/应该归咎于这种减速？
我只看到 JIT 在一个奇怪的错误中花费了很长时间（大于 1 秒），该错误与模板化集合中的模板化项目有关（参见下面的编辑）。
无论如何，您看到它“移动”的事实肯定向我表明这可能不是问题所在。为了尝试明确地确定这一点，我会考虑使用 RPM 来查看延迟前后发生的情况。
预期的 JIT 时间是一件非常模糊的事情，因为有很多因素会影响它。处理器速度是一个显而易见的问题，但不太明显的可能是应用存储介质和设备内存压力等问题。
存储介质会影响 JIT 速度，因为 JITter 在需要 JIT 时必须从介质中拉出 IL，如果拉得很慢，那么 JIT 就会很慢。
内存压力是一项艰巨的任务，并且会对 CE 设备产生严重影响。这里的问题是，当您开始耗尽内存时，EE 将在收集期间开始投放 JITted 代码 - 除了调用堆栈之外的所有内容。现在，如果你在一个例程中，例如，调用一些工人或助手的东西，或者有一个线程正在运行，那么那个助手方法可能会被调整、JITted、pitched JITted 等。这被称为“鞭打。”
使用 RPM 识别后者相当容易（修复它可能不是那么容易）。查看要频繁提升的代码数量，并寻找提升数量的增加与您感知的锁定之间的强相关性。
编辑：我终于在这里找到了错误描述。
JIT（和 GC）计时器等可以在这里找到：
.NET Compact Framework 中的性能计数器 ( http://msdn.microsoft.com/en-us/library/ms172525.aspx )
在 .NET Compact Framework 上监控应用程序性能第一部分 - 启用性能计数器 ( 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 )
问候，坦伯格