Memory Profiling with DotTrace Questions

Question

I ran dotTrace on my application (which is having some issues).

IntPtr System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)

Void System.Windows.Forms.UnsafeNativeMethods.WaitMessage()

Are the two main functions that came up, taking about 94% of the application time.

Since I didn't know what these two functions were, I ran through my code line by line. It runs smooth and efficiently until a point where it just hangs. "newFrm.Show()".

The newFrm only contains a textbox. The larger the file I load into the text box (it's a notepad program), the longer it takes. Now normally this makes sense, but it takes about 30 seconds for a 167 kB file.

Now I'm not sure what to do. It runs incredibly slow/stops functioning when you load a textfile and try to resize the window containing the text file too.

Then I realized that it is only struggling to open text files with a long string of hex inside (ie) "XX-XX-XX-" etc. With other similarly sized files it struggles with resizing somewhat, but opens within a couple seconds.

Does this have something to do with the textbox properties? I've set it to multiline and set maximum characters to 0 (so unlimited).

How do I solve this issue? Is there some way I can see what is being called in those functions?

Answer 1

It is normal for a profiler to show that most execution takes place in those Windows API calls. CallWindowProc() runs the default message handler for a control, you are measuring how long it takes for the native edit box control built into Windows to handle your text file. WaitMessage() spins, waiting for a message from Windows that something interesting happened. This makes profiling GUI code difficult, you have to lift the code you wrote into a unit test style program. Not practical here, you didn't write any of the code that is taking all the CPU cycles.

Your problem is that TextBox isn't a very good text editor. It doesn't have any of the optimizations that you'd find in a full-blown editor. Be sure to turn the WordWrap property off, that's especially expensive. And be sure not to fill the TextBox line-by-line from a file, that's very slow as the native control constantly has to re-allocate its buffer. Use File.ReadAllText() or use a StringBuilder, then assign Text.

Something like the open source ScintillaNET does a much better job.