我们的应用程序中存在虚幻延迟。这可以追溯到第一次碰到物体时的单身人士的初始化，并被归咎于JIT。我并不完全相信这一点，因为没有测量JIT（或者是否存在）的机制，整个延迟时间为7秒。 JIT七秒钟？！？这可能是虚幻的吗？Compact Framework和JIT。需要多长时间
无论哪种方式，我很难指责一个人不易衡量的事情。当我回顾一下这个问题时，我注意到了一堆代码，并观看了应用程序中其他地方的七秒延迟“跳跃”。暗示它在某处发生在后台进程上（我想这会将JIT作为潜在原因）。
只是为了好玩，如果有一个静态对象碰巧引用了很多其他的对象，那么任何人都有一个关于JIT可能需要多久的规则？有没有人有进一步的参考资料，所以我可以更多地了解JIT，所以我有机会了解JIT是否应该归咎于这种放缓？
我只看到JIT需要花费很长时间（大于1秒）处理模板化集合中模板化项目的奇怪错误（请参阅下面的编辑）。
无论如何，你看到它“移动”的事实绝对表明，它可能不是问题。为了试图明确地确定这个问题，我会考虑使用RPM来查看延迟之前和之后发生的事情。
预期的JIT时间是一个非常模糊的事情，因为有太多的因素可以影响它。处理器速度是显而易见的，但不太明显的可能是应用程序存储介质和设备内存压力等问题。
存储介质可能会影响JIT速度，因为JITter需要将介质从介质中提取出来，并且如果拉动速度慢，那么JITting会很慢。
内存压力是一个艰难的问题，并可能对CE设备产生严重影响。这里的问题是，当你开始用完内存时，EE将在收集期间开始投入JITted代码 - 除了调用堆栈之外的所有内容。现在，如果你在例程中调用一些工作或辅助工具，或者有一个线程正在运行，那么该辅助方法可能会变得不稳定，被打乱，被打上JIT，等等。这被称为“鞭打“。
使用RPM识别后者相当容易（修复它可能不那么容易）。看看频繁加注的代码数量，并寻找球场数量增长与感知锁定之间的强相关性。
编辑：我终于找到了the bug description here。
JIT（和GC）定时器等可以在这里找到：
性能计数器在.NET Compact Framework的第一部分.NET Compact Framework的 （http://msdn.microsoft.com/en-us/library/ms172525.aspx）
监测中的应用性能 - 启用性能计数器（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框架
（http://msdn.microsoft.com/en-us/library/w8f5kw2e(VS.80).aspx）
问候， tamberg
感谢您的错误描述。 v。有趣而且有趣。 – Quibblesome 2009-01-22 10:12:45