Forum

Hi,

we are preparing a new version of our software. Starting with this new version, we wana give our customers the posibility to switch between different themes. So we have to modify our source code in this way: Use CExtResizableDialog instead oc CDialog, use for static text CExtLabel, ... include a DDX_Control for each element. All works fine, but this result in an unsuitable runtime behavior. Switching dialogs need so much time, build up terrible long time. Sometimes buttons has to be pressed twice, because the programm is not reacting in time. Example: loading a document need more than 4 seconds, with the old version less than 1 second. The programm is reaction l ike working with an old 286 :-(

What do we wrong? How can we speed up execution time?

TIA

Willi

Debug is an unlimited number of times slower. Especially Prof-UIS grids. We are using heavy assertions everywhere. This is needed for bug searching both in Prof-UIS and your apps. Release is 20% . . . 30% slower rather than 3 times like you wrote.

It is ok and no problem, when Debug need such a long time. But I’m talking about the Release Version. On some "slow" (I5) PCs, it need sometimes 3-4 sec to open a simply dialog. When running the old version without themes and resizeable dialogs, it need about half a second. Additional it not allways need such a long time, sometime it opens in time, sometimes it need 4 sec.

Seems, the prog ist waiting for? What? idle? Waiting?

PLS help

Willi

Please compare the performance of your app with some Prof-UIS sample app. If yours is slower, then we need to reproduce the performance problem of your app somehow to provide you with advices. Typically performance problems are brought by heavy timer processing code, a lot of timers are running, heavy thread idle state processing code, heavy command updating code.
Please do not forget to invoke the SetAutoSubclassChildControls() API in constructors of the CExtResizableDialog-derived classes. This will subclass all the common controls with dynamic instances of Prof-UIS C++ classes. I.e. you will not need to add CExtLabel instance for each static manually. The same is related to combo boxes, buttons, check boxes, radio buttons, editors.

Comparing with the Your sample Apps is not real fair: in Your samples, You create 1,2 or 3 dialogs, not more. In the real world, I have to create 20 up to 40 dialogs. I’m also not sure, how to find out, where the runtime is wasted. Measuring the time to switch between dialogs is very hard. So my fisrt try is to find out, what code need a lot of time, in my try: Open an existing document, create all needed dialogs and display at screen.

a) I started with only a very little Prof-UIS elements (old version): 1.1 sec

b) replaced all CDialog with CExtResizableDialog: 1.8 sec

c) For each element used CExtLabel, CExtEdit, ... (BUT NOT CExtComboBox): 3.6 sec

d) like c) but now also used ( about 70) CExtComboBox: 5.7 sec

So, it seems, that CExtComboBox needs so much time. Done a cross-check:

e) No CExtResizableDialog, No CExtLabel, CExtEdit, only CExtComboBo: 2.6 sec

From substrcatime time of c) from time of d) and adding base time of a) I would exspect a time of e) 3.7 sec.

So, it seems to me, that ist is very important, how much Prof-UIS elements are called. And this is only an example, I have a lot of documents with lot of different dialogs. The time measurement was done during lod of document, without any timers running, no idle processing, omly very few command update code.

Waht do I wrong? Where can I speed up?

TIA

Willi

P.S. Tnx, I know the SetAutoSubclassChildControls API, but for finding out the time consumption, I do not use it. I have tried, I get exact same timeing, when using this function instead of declaring and calling by hand