2
votes

I've got a special combo box with a very long list of items (a few thousand) that has to be calculated when you open it. When I was testing something, I was horrified to find that it took about a minute to open. So I hooked the program (same build, same options) up to Sampling Profiler to see what was taking so long, and it only took about 5 seconds to open. I tried running it directly from Windows, and this time it only took 2-3 seconds, which is what I expected.

So why does the exact same EXE crunch the numbers more than 25 times slower when the Delphi debugger is hooked up to it? It's not anything obvious like conditional breakpoints being evaluated. It seems that just the presence of the debugger is slowing it to a crawl. Does anyone know why?

1
Is it producing a lot of debug output (OutputDebugString)? Anything showing up in the event log?Zoë Peterson
@Craig: Yes it is. Very good job psychic debugging! It's calling OutputDebugString twice per iteration of a tight loop. Put that as an answer and I'll accept it.Mason Wheeler
OutputDebugString is like a breakpoint: it puts the string in the event log, and forces it to scroll with all the implied handling...Francesca
You might want to use a real logging tool instead of OutputDebugString, as Delphi's support for OutputDebugString is really slow (I believe it's mainly due to how Delphi draws/refreshes its event list for every log entry). You could check out our SmartInspect logging tool, but any modern logging system should be a dramatic improvement.Dennis G.

1 Answers

7
votes

Repost: Is it producing a lot of debug output (OutputDebugString)? Anything showing up in the event log?