Asp Forum - Using OutputDebugString too much can cause slowness in GUI response

(nobody)

8/20/2010 2:29:00 PM

FYI, I have been having problems with a ListView with about 100 items, and
when I try to scroll vertically or horizontally by dragging the scroll bar,
it doesn't catch up immediately, but it looks highlighted and frozen, and
catches up later.

It turned out the reason for it was that I was using OutputDebugString too
much, printing the text for each item and sumitem(There are 8 columns in
this list view), and DebugView was open to view the output. When I close
DebugView, the problem is gone. I was using OutputDebugString at a rate of
1000/Second.

The items also appeared to flicker more frequently, I am not sure if it's
related.

Just a FYI, in case someone else is having this problem.

6 Answers

Mayayana

8/21/2010 12:32:00 PM

I've seen you mention this function before.
I just looked up both, but I don't get it.
What's the advantage/reason for using
OutputDebugString rather than Debug.Print?
Likewise, what's the advantage of DebugView
over the Immediate window?

| FYI, I have been having problems with a ListView with about 100 items, and
| when I try to scroll vertically or horizontally by dragging the scroll
bar,
| it doesn't catch up immediately, but it looks highlighted and frozen, and
| catches up later.
|
| It turned out the reason for it was that I was using OutputDebugString too
| much, printing the text for each item and sumitem(There are 8 columns in
| this list view), and DebugView was open to view the output. When I close
| DebugView, the problem is gone. I was using OutputDebugString at a rate of
| 1000/Second.
|
| The items also appeared to flicker more frequently, I am not sure if it's
| related.
|
| Just a FYI, in case someone else is having this problem.
|
|

ralph

8/21/2010 2:08:00 PM

On Sat, 21 Aug 2010 08:31:57 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:

> I've seen you mention this function before.
>I just looked up both, but I don't get it.
>What's the advantage/reason for using
>OutputDebugString rather than Debug.Print?
>Likewise, what's the advantage of DebugView
>over the Immediate window?
>

Because the Immediate Window is only available when a component or
program is run within the VB IDE, therefore you can only instrument
non-native compiled (pcode) debug releases, and only on boxes where VB
is installed.

Other minor advantages are:
1) Debug viewers usually have larger buffers
2) You can view the output of more than one component in one place
which is not only convenient but can provide a better view of
concurrences.

-ralph

Jim Mack

8/21/2010 2:09:00 PM

Mayayana wrote:
> I've seen you mention this function before.
> I just looked up both, but I don't get it.
> What's the advantage/reason for using
> OutputDebugString rather than Debug.Print?
> Likewise, what's the advantage of DebugView
> over the Immediate window?

The obvious one is that they work with compiled code, not just in the
IDE.

--
Jim Mack
Twisted tees at http://www.cafepress.c...
"We sew confusion"

(nobody)

8/21/2010 2:43:00 PM

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:i4ogsj$njl$1@news.eternal-september.org...
> I've seen you mention this function before.
> I just looked up both, but I don't get it.
> What's the advantage/reason for using
> OutputDebugString rather than Debug.Print?
> Likewise, what's the advantage of DebugView
> over the Immediate window?

If you have subclassing code that crashes the IDE when you stop it, then you
have to compile it, but Debug.Print output won't show up.

Note that when Debug.Print is compiled into an EXE, the call is not removed,
but the result is discarded. If you have a statement like:

Debug.Print "LicenseKeyVerify: UserName = " & UserName

Then anyone can view your EXE with a Hex editor, or trace where the call is
in the disassembly, and break the licensing scheme if it's shareware.

However, Debug.Assert is removed from the EXE, so don't add code that take
action like a function call. You can test this be compiling the following:

Option Explicit

Private Sub Form_Load()
Debug.Print MsgBox("Hello from Debug.Print")
Debug.Assert vbOK = MsgBox("Hello from Debug.Assert vbOK")
Debug.Assert vbYes = MsgBox("Hello from Debug.Assert vbYes")
End Sub

When I run this in the IDE using VB6, I get all three MsgBoxes, but the IDE
breaks at the last Debug.Assert because the result is False. When I run this
in an EXE, I only see the first MsgBox.

ralph

8/21/2010 5:19:00 PM

On Sat, 21 Aug 2010 10:43:28 -0400, "Nobody" <nobody@nobody.com>
wrote:

>"Mayayana" <mayayana@invalid.nospam> wrote in message
>news:i4ogsj$njl$1@news.eternal-september.org...
>> I've seen you mention this function before.
>> I just looked up both, but I don't get it.
>> What's the advantage/reason for using
>> OutputDebugString rather than Debug.Print?
>> Likewise, what's the advantage of DebugView
>> over the Immediate window?
>
>If you have subclassing code that crashes the IDE when you stop it, then you
>have to compile it, but Debug.Print output won't show up.
>
>Note that when Debug.Print is compiled into an EXE, the call is not removed,
>but the result is discarded. If you have a statement like:
>
>Debug.Print "LicenseKeyVerify: UserName = " & UserName
>
>Then anyone can view your EXE with a Hex editor, or trace where the call is
>in the disassembly, and break the licensing scheme if it's shareware.
>
>However, Debug.Assert is removed from the EXE, so don't add code that take
>action like a function call. You can test this be compiling the following:
>
>Option Explicit
>
>Private Sub Form_Load()
> Debug.Print MsgBox("Hello from Debug.Print")
> Debug.Assert vbOK = MsgBox("Hello from Debug.Assert vbOK")
> Debug.Assert vbYes = MsgBox("Hello from Debug.Assert vbYes")
>End Sub
>
>When I run this in the IDE using VB6, I get all three MsgBoxes, but the IDE
>breaks at the last Debug.Assert because the result is False. When I run this
>in an EXE, I only see the first MsgBox.
>

Well, might as well add DebugBreak to the pile.

Private Declare Sub DebugBreak Lib "kernel32" Alias "DebugBreak" ()

This replaces VBs "Debug.Assert False" to trigger an outside debugger.

Dee Earley

8/25/2010 5:11:00 PM

On 20/08/2010 15:29, Nobody wrote:
> FYI, I have been having problems with a ListView with about 100 items, and
> when I try to scroll vertically or horizontally by dragging the scroll bar,
> it doesn't catch up immediately, but it looks highlighted and frozen, and
> catches up later.
>
> It turned out the reason for it was that I was using OutputDebugString too
> much, printing the text for each item and sumitem(There are 8 columns in
> this list view), and DebugView was open to view the output. When I close
> DebugView, the problem is gone. I was using OutputDebugString at a rate of
> 1000/Second.

Yeah, the calls are serialised and block on each other and the listeners.
Note that even without a listener, they still block on each other which
will cause problems if used from multiple threads/processes.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

microsoft.public.vb.general.discussion

Using OutputDebugString too much can cause slowness in GUI response

(nobody)

Mayayana

ralph

Jim Mack

(nobody)

ralph

Dee Earley

x Login to ForumsZone