I have an application that logs messages to the screen using a TextBox. The update function uses some Win32 functions to ensure that the box automatically scrolls to the end
How are you determining the memory usage? You'd have to watch the CLR memory usage for your application, not the memory used by the system for the whole application (you can use Perfmon for that). Perhaps you are already using the correct method of monitoring.
It seems to me that you are using StringBuilder
internally. If so, that would explain the doubling of the memory, because that's the way StringBuilder works internally.
The GC.Collect()
may not do anything if the references to your objects are still in scope, or if any of your code uses static variables.
EDIT:
I'll leave the above, because it may still be true, but I looked up AppendText
's internals. It does not append (i.e., to a StringBuilder), instead, it sets the SelectedText
property, which does not set a string but sends a Win32 message (string is cached on retrieval).
Because strings are immutable, this means, for every string, there will be three copies: one in the calling application, one in the "cache" of the base Control
and one in the actual Win32 textbox control. Each character is two bytes wide. This means that any 1MB of text, will consume 6MB of memory (I know, this is a bit simplistic, but that's basically what seems happening).
EDIT 2: not sure if it'll make any change, but you can consider calling SendMessage
yourself. But it sure starts to look like you'll need your own scrolling algorithm and your own owner-drawn textbox to get the memory down.