Debug output slow

[carlox]

I wonder if there is some way to speed up the debug output in LabWindows.

When a program is debugged in LabWindows all the debug output is routed to the Debug Window, so we see strings from our own DebugPrintf() statements, and strings from OutputDebugString() from any other DLL linked by our process.

This string output is SLOW, and the slow down affects even separate threads in our experience.
For example, I have here a program with several threads that manage CAN networking.

As soon as I open, in the UI thread, a FileSelectPopupEx the underlying comdlg32.dll starts to emit a lot of debug messages (Win 10 pro 1709) and all communication background fails in unpredictable ways. 
This could be helpful if my intention was to develop some time independent handshake, but this isn't the case.
The text rows in the debug window appears slowly, as they come from a serial terminal of past age, and I can't believe this is the best it can be done to show those messages: for sure it's missing some queuing - or whatever buffering - between process and debugger.

As preventive measure, I've routed all my own debug messages to a custom XDebugPrinf() that sends messages via UDP to the simplest server you can imagine, but this of course does not work for system DLLs.
I'm stuck in nondebuggable code sections, and for the first time in past years I'm facing something I cannot workaround.
Very frustrating.
If only I could tell CVI "please ignore OutputDebugString"...

[djac91]

This is so true. i recently experienced a similar issue where my high speed tcp threads were getting slowed down and ultimately filling up memory and crashing due to use of debugprintf function. After those were removed everything was back to normal.

[Jattie]

This is not a CVI problem. This is a problem across all platforms using threading. If you output text you a screen  anywhere in  any operating system in fact, it slows down everything. That is why you set debug levels and create debugging to log files instead. 

So debugging needs to be part of your code design from the beginning and I suggest incorporating levels too.

[carlox]

@Jattie

If you read carefully what I have written, you will discover I already have directed all my debug output other way, redirecting it in a UDP channel so I can receive it on another machine of my network (and I have debug levels, too).

And yes, debug IS part of my code and system design from the beginning.
My toolbox is full of tricks and tools.  

My problem is that the CVI debug output window is plagued by messages coming from comdlg32.dll. 

Comdlg32.dll is a system Windows DLL, and I have no control on its debug output, of course. 

CVI debugger behaves absolutely bad and it freezes temporarly other threads (or slows them down dramatically, result is the same) , while it should try to be as fast as possible to avoid any side effect. 

In my experience, it's much slower than other development enviroment in the same situation.

For example, if the OutputDebugString() strings are captured by DbgView, while running the very same program outside CVI, there is no sensible slowdown and my whole system can work without timeouts.

And DbgView has the same "problem" to output text to a screen.