我們的應用程序中存在虛幻延遲。這可以追溯到第一次碰到物體時的單身人士的初始化，並被歸咎於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