我正在研究實時成像系統。C＃後臺線程在UI中導致滯後
UI線程：通過定時器以14 fps的速度從攝像頭抓取圖像並進行一些處理/顯示。每2秒鐘，通過處理選擇3張圖像（每張大約1mb），寫入磁盤。這些放在共享隊列中。
第二個線程：將映像出隊並寫入磁盤。已被賦予「最低」的優先權。
當第二個線程正在執行寫操作時，它會從UI線程中消耗一個明顯的perf塊，並導致捕獲降至14 fps以下。不能接受的。
我能在這裏做什麼？我不介意如果寫入需要更長的時間並排隊等待，那麼會有大量的RAM和常規暫停，以便寫入時間能夠趕上。關鍵因素是UI線程有足夠的果汁工作在14 fps。
爲了得到一個認真的答案，你應該使用某種探查器工具。如果你搜索一個stackoverflow或谷歌，你會發現很多。大多數情況下，你必須爲它們付費，但幸運的是，還有一些試用版本可以測試以發現問題。
但我沒有任何分析器的猜測是，磁盤上的I/O操作會導致性能問題。所以，如果你嘗試使用SparseFile和/或MemoryMappedFile（我知道它是.Net 4，但是它只是一個對Win32 API的包裝，你可以從那裏提取類並使用它它在.Net 2）。
也許你應該在執行操作後將文件保存到不同的位置。有可能該文件在處理時被鎖定，並且UI線程等待它被釋放。
正如其他人所說：硬實時不會在這裏工作。
試着找出設備是否共享資源（壞例子：在同一個USB總線上，磁盤和相機）。與分析器一起檢查它是否是限制捕獲或IO的CPU。也許這只是你的代碼的錯誤（泄漏資源，浪費週期）。沒人能說，但你可以（也應該）檢查它。
可能的「解決方案」，這取決於你的發現：
使用隊列（MSMQ例如），只是堆放圖像，從來沒有從那裏讀（甚至沒有降低線程的優先級），直到你達到你的「暫停」。這實際上需要「大量的RAM」。
你是否從後臺線程調用任何UI更新？它確實不應該影響你的用戶界面。 – 2010-03-03 12:43:11
等一下，你爲什麼要在UI線程上從相機中抓取圖像？ – 2010-03-03 12:44:37
沒有人擁有單核CPU了。你正在做某種鎖定，會減慢捕捉圖像的線程。 – 2010-03-03 13:40:53