Profiling Performance - Where is the missing Time?

[Olaf Doschke]

I have an application in maintenance, which starts slow and about 50% of the initialization time doesn't show up in a coverage.log I did via [tt]SET COVERAGE TO some.log[/tt]

The log record for DO form reflects the real world time I can also stab, about 4 seconds.
The coverage log of all stack levels of code from the DO FORM line up to getting back after DO form sums up to only two seconds (roughly).

Was mentionable is a calendar control (dayview.ocx) used (the vendor of that doesn't exist anymore) which has the Font object typical for VB (classic), so you have ocx.object.Font.Size and so on. I can't set these properties. Side question: Does anyone know how to cope with this. Even in ActiveX control design-time properties I only get this dialog - disabled and greyed out:

The German Vocabulary - though not that importatn, it's clearly a font selection dialog:
Eigenschaften = Properties
Schrfitarten = Fonts
Eigenschaftsname = Property Name
Schrfitart = Font
SchriftStil = font Style
Größe = Size
Effekt = Effects
Durchgestrichen=Strike-Through
Unterstruchen=Underline
Beispiel = Example
Abbrechen = Cancel

Getting back to the coverage logging missing time: I know views in the data environment of a form will take time and not log into the coverage log, the only other thing I can think of is properties set to =expression and base class behavior.

Any other ideas for what to look?
What else is not logged into coverage.log?

By the way, it doesn't matter if I log at design time with source code or in the EXE and the EXE is compile with debug info, so I do get the same amount of log lines in both cases.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[fdbozzo69]

Hi Olaf:

You could try testing things separated.

In example:
- You can create a test form with just the calendar to check how much time it takes alone (with the original date/time settings)
- You can create another test form with just the tables/views environment, to see how long it takes

Possible solutions:
- For the calendar: I suggest to replace it with something VFP based. There are a lot of VFP-calendars out there that works and looks very well and without delays.
- For the views/tables: Normally having them in the DE is documented as being the fastest option, but sometimes is preferable to "look as faster" than than being faster and "look slower". It's a matter of user-perception, but it works this way: You can have a one-time method execution on the Activate event (controlled by a "l_Executed" flag/property) that open the tables/views and do all the neccesary setup, so when you start the form you can see it almost instantly and at the time the form is shown your setup code is executed, so when the user take a look at the form to start using it (few secs to look and recognize the objects/options and take a decission) your setup code executes almost without being perceived.
I use this technique in heavy forms, even in one in which I'm working now in what I need to show 2 panels that take few seconds the fill with info, so I show first the form and finally I fill these panels with a progressbar over each one, which serves as a cool distraction and shows that there is some processing happening.

Fernando D. Bozzo

 

[Olaf Doschke]

Meanwhile there is no doubt the OCX is the major component, because in a process of switching a date and refreshing appointment data about that the two major tie consumptions are about getting data (understandable) but more so, simply sizing up text. This control seems to have a legacy starting at a time when there even was no GDI+ used to draw fonts. I still haven't figured out for which reasons it's sometimes extremely slow and sometimes at least bearable, but it must be related to something that should run in split seconds, just rendering a bit of text.

And that becomes very obvious from doing coverage logging of the switching proces in which case all of the time spent on this date switch is recorded.

I would still like to get a general hint on how we could find out which events consume time, if there is no code in them, I have the feeling there is something going on in the native behavior of some of the OCX controls that looks for a non existing font or gdi function or anything else missing under Win10, because it runs faster in a VM on XP.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

Olaf,

in the past i've had two circumstances where time went missing; i don't think either are relevant here but i'll mention them anyway.

1. grids were binding to a table on a network drive before i had the chance to set their recordsource to a local cursor. problem went away when i set the recordsource at design time to a dummy empty cursor.
2. system.app was being loaded from a network drive and that, in combination with breaking the progcache setting, meant a lot of GDI related functions took a long time as code presumably got paged in and out.

n