×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Profiling Performance - Where is the missing Time?

Profiling Performance - Where is the missing Time?

Profiling Performance - Where is the missing Time?

(OP)
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 SET COVERAGE TO some.log

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

RE: Profiling Performance - Where is the missing Time?

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

RE: Profiling Performance - Where is the missing Time?

(OP)
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

RE: Profiling Performance - Where is the missing Time?

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close