How might I find out the source of long delays on resizing the main form?

Question

I have a D2006 app that contains a page control and various grids, etc on the tabs. When I resize the main form (which ripples through and resizes just about everything on the form that is aligned to something), I experience long delays, like several seconds. The app freezes, the idle handler is not called and running threads appear to suspend also.

I have tries pausing execution in the IDE while this is happening in an attempt to break execution while it is in the troublesome code, but the IDE is not taking messages.

Obviously I'm not expecting anyone to point me at some errant piece of code, but I'm after debugging approaches that might help me. I have extensive execution timing code throughout the app, and the long delays don't show up in any of the data. For example, the execution time of the main form OnResize handler is minimal.

Murvyn

Then these threads are waiting for the main thread, maybe due to Synchronize. – Hystero

What is in, or what are, the the "grids" ? DBGrid/StringGird? – Tippets

@Tippets - they are TDrawGrids and TStringGrids. The DrawGrids are all rendered from stuff in memory – Murvyn

Don't forget about AQTime, it's a great profiler. A lite version comes with Rad/Delphi XE, and there's trial around I think. It's commercial, and worth it. – Quinsy

Answer 1

If you want to find out what's actually taking up your time, try a profiler. Sampling Profiler could answer your question pretty easily, especially if you're able to find the beginning and the end of the section of code that's causing trouble and insert OutputDebugString statements around it to narrow down the profiling.

Bainbrudge

Hi @Mason. I get --------------------------- Access violation at address 0040770B in module 'SamplingProfiler.exe'. Read of address 00E30000. --------------------------- when I try to start profiling. – Murvyn

@rossmcm: Then try reporting it on the forum. Access violations are pretty easy to track down if you can come up with a reproducible test case. – Bainbrudge

"Your account is still awaiting admin approval" – Murvyn

Answer 2

Run your application in AQTime's performance profiler (included with XE, but you can get a time-limited version from their website).

Do some fanatic resizing for a while, and then stop the application.

After that, you'll see exactly which function was called many times, and where most time was spent.

Diluvium

Answer 3

OK. Problem solved. I noticed that the problem only occurred when I had command-line switches enabled to log some debug info. The debug info included some HTTP responses that were written to a debug log (a TMemo) on one of the tabs. When the HTTP response included a large block with no CR/LFs the TMemo wrapped it. Whenever I resized the main form, the TMemo resized and the control had to render the text again with the new word wrapping.

To demonstrate:

• start a new Delphi project
• drop a TMemo onto the form
• align it to Client
• compile and run
• paste a large amount of text into the TMemo
• resize the main form

I won't award myself the answer, as I hadn't really provided enough info for anybody else to solve it.

BTW @Mason - would SamplingProfiler have picked this one up - given that the execution is inside the VCL, and not in my code?

Murvyn

Yes, it would have. It works by sampling the program state and comparing it against a map file, and the map file includes data for the standard libraries as well as for your code. (That doesn't necessarily mean it would be easy for you to make sense of the data if you weren't familiar with VCL internals, but it would definitely have picked it up.) – Bainbrudge

If you turn off TMemo word-wrapping it gets faster? – Quinsy

@Warren, By some orders of magnitude if the text long enough to be wrapping – Murvyn

Answer 4

A brute-force approach that may give results.... Put a debug message to OutputDebugString() from every re-size event, sending the name of the control as the string to be displayed. This may show you which ones are being called "a lot".

You may have a situation where controls are bumping each other, setting off cascading re-size events. Like 3 siblings in the back seat of a compact car, once they start jostling for position, it can take a while for them to "settle down".

Don't make me turn this car arround....

The debug log (viewable in the IDE, or with an external ODS viewer), may show you which ones are causing the most trouble, if they appear multiple times for one "user-initiated re-size event".

Founder