在Windows上加速文本輸出，用於控制檯

Question

我們有一個應用程序具有一個或多個文本控制檯窗口，這些窗口基本上都表示串行端口（文本輸入和輸出，逐個字符）。這些窗口已經成爲目前代碼的主要性能問題......我們設法在這些窗口中花費大量時間。

當前代碼的結構是讓窗口過着自己的小生活，主應用程序線程通過「SendMessage（）」調用驅動它。這消息傳遞似乎是令人難以置信的開銷的原因。基本上，通過操作系統繞道感覺是不對的。

請注意，我們會在適當的位置繪製文本行，以便輕鬆優化。

我無法在Windows編碼的專家，所以我要問的社區如果有一些其他架構，以推動文本的顯示比發送這樣的消息窗口？它似乎很重量級。

注意，這是在C++或純C，作爲主應用程序是一個可移植的C/C++ /其他一些語言程序也運行在Linux和Solaris。

我們做了一些更多的調查，似乎有一半的開銷是使用SendMessage準備和發送每條消息，另一半是實際的屏幕繪圖。該SendMessage函數在同一文件中的函數之間做...

所以我想下面給出的所有建議是正確的：

• 查找有多少事情是重繪
• 借鑑的東西直接
• 塊繪製操作及時發送，不要將每個字符發送到屏幕上，目標是串行控制檯的10到20 Hz更新速率。

您可以接受所有的答案？

Answer 1

我同意Will Dean的看法：控制檯窗口或文本框中的圖形本身就是性能瓶頸。你首先需要確定這不是你的問題。你說你畫出每一行作爲一個整體，但即使這可能是一個問題，如果數據吞吐量太高。

我建議您不要使用SendMessage將數據從主應用程序傳遞到文本窗口。相反，使用其他一些通信手段。這些是在同一個過程中嗎？如果沒有，你可以使用共享內存。即使在磁盤上的文件也可以在某些情況下使用。讓主應用程序寫入此文件並從中讀取文本控制檯。您可以將SendMessage通知發送到文本控制檯以通知它更新視圖。但是，不要在新行到達時發送消息。定義兩個後續更新之間的最小間隔。

Answer 2

你應該嘗試分析正確，但代替的，我將停止擔心SendMessage函數，這幾乎可以肯定不是你的問題，想想窗口本身的重新劃分。

你描述這些是'文本控制檯窗口'，但後來說你有多個 - 他們實際上是Windows控制檯？或者他們是你的應用程序繪製的東西？

如果是後者，那麼我會考慮測量我的畫圖代碼，以及每次更新時是否使窗口失效太多。

Answer 3

輸出窗口是同一個應用程序的一部分嗎？它幾乎聽起來像他們不是...

如果他們，你應該看看Observer design pattern遠離SendMessage（）。我已經將它用於相同類型的用例，它對我來說非常合適。

如果你不能做這樣的改變，也許你可以緩衝你的輸出爲100毫秒的東西，這樣你就不會有這麼多的每秒發出的消息，但它也應該以一個舒適的速度更新。

Answer 4

輸出窗口是否爲 相同的應用程序的一部分？它幾乎聽起來像 像他們不是...

是的，他們都在同一過程。

我沒有寫這段代碼......但是好像SendMessage在一個應用案例中有點沉重。

您介紹這些「文本控制檯 窗口」，但後來說你有 多種人 - 他們真的正在 的Windows控制檯？或者他們 你的應用程序正在繪製的東西？

我們的應用程序正在繪製它們，它們不是普通的Windows控制檯。

請注意，我們還需要在用戶鍵入控制檯時返回數據，因爲我們經常有交互式串行會話。可以認爲它與您在串行終端程序中看到的非常相似 - 但使用外部應用程序顯然比現在更昂貴。

如果你不能作出這樣的改變， 或許你可以緩衝自己的輸出 這樣的事情100ms的，這樣你 沒有那麼多了正在進行的消息 每秒，但應還可以舒適的價格更新 。

好點。現在，每個字符輸出都會導致發送一條消息。

而當我們在換行時滾動窗口，然後我們逐行重新繪製它。

請注意，我們也有一個任意大小的回滾緩衝區，但向後滾動是一個交互式的情況下性能要求低得多。