We have an application that has text console window(s) that all essentially represent serial ports (text input and output, character by character). These windows have turned into a major performance problem in the way they are currently code...
The current code is structured by having the window living its own little life, and the main application thread driving it across "SendMessage()" calls. This message-passing seems to be the cause of incredible overhead. Basically, having a detour through the OS feels wrong.
We do draw text lines as a whole where appropriate, so that optimization is already done.
Is there some other architecture to drive the display of text in a window than sending messages like this? It seems heavyweight.
This is in C++ or plain C, as the main application is a portable C/C++/some other languages program that also runs on Linux and Solaris.
Half of the overhead is preparing and sending each message using SendMessage, and the other half is the actual screen drawing. The SendMessage is done between functions in the same file...
All the advice given below is correct:
I agree with Will Dean that the drawing in a console window or a text box is a performance bottleneck by itself. You first need to be sure that this isn't your problem. You say that you draw each line as a whole, but even this could be a problem, if the data throughput is too high.
I recommend that you don't use the SendMessage to pass data from the main application to the text window. Instead, use some other means of communication. Are these in the same process? If not, you could use shared memory. Even a file in the disk could do in some circumstances. Have the main application write to this file and the text console read from it. You could send a SendMessage notification to the text console to inform it to update the view. But do not send the message whenever a new line arrives. Define a minimum interval between two subsequent updates.