Open topic with navigation
WTSupported in traditional Synergy on Windows
USupported on UNIX
VSupported on OpenVMS
By providing profiling information about your programs, the Synergy DBL Profiler helps you determine where and how you can best optimize them. A profiled routine counts the CPU time it uses (in ticks), including any system calls, and it counts the number of times the routine is XCALLed. It also shows I/O on Windows and both I/O and page faults on OpenVMS.
Depending on which system options you’ve set, profiling can also include any Synergy DBL subroutines that are XCALLed by the current routine. In the latter case, the total CPU time for a program can be counted many times, and the total CPU time is the time taken by the root module, rather than the sum of all the modules.
On UNIX and OpenVMS, the profiler calculates accumulated CPU time. On Windows, you have a choice of (low‑granularity) accumulated CPU time or (high‑granularity) elapsed CPU time.
To profile your routines,
|1.||If you are only profiling specific routines (rather than all routines), compile those routines using the profiling compiler option (‑u on Windows and UNIX or /profile on OpenVMS).|
|3.||Run the resulting program.|
|4.||Decode the profile.dat or lines.dat file that was created to get the profile results.|
You can enable profiling in one of two ways.
Use this option
The current routine if the profiling compiler option is specified
The current routine and all routines XCALLed by the current routine if the profiling compiler option is specified
Synergy programs at the line level. (Note that you cannot specify a list of routines to exclude when you use this option.)
Running a program that was compiled with profiling enabled outputs a file called profile.dat (or lines.dat if system option #52 is set). This file is the data file that is used to get the profile. (See Decoding the profile.dat or lines.dat file below.) On OpenVMS, this file is written to SYS$SCRATCH:. On other systems, it is written to the current directory.
Depending on which system option was set when you compiled, either profile.dat or lines.dat was created.
To decode the profile.dat file, enter
dbr DBLDIR:profile [-x exclusion_file]
The profile program interprets profile.dat and outputs the results to a file called profile.lst. When you run profile, you can specify an exclusion file that contains a list of routines to exclude from the profile output. The routine names listed in this text file can be on one or more lines and must be separated by commas. (Although the exclusion file option is available on all platforms, it provides the greatest benefit on Windows, due to the granularity of the measurements.) If the ‑x option is not specified, the profiler uses the default exclusion file, tkexclude.txt, which is distributed with UI Toolkit in the directory pointed to by the WND environment variable. This file is provided because when elapsed CPU time is profiled on Windows, Toolkit input routines such as I_INPUT_P can consume a large amount of time. Excluding the Toolkit input routines enables you to get a more accurate idea of how much CPU time is actually being used.
To decode the lines.dat file, enter
The profline program interprets lines.dat and outputs the results to a file called lines.lst, which is sorted according to which statements are used most often.
Routine profiling is only as accurate as the CPU times posted to your process by the operating system. Especially on faster systems, misleading results can be generated. On a fast CPU, 10 millisecond ticks encompass a lot of Synergy DBL instructions.
On OpenVMS, the DIO count includes any I/O required to write the profile.dat file, which can account for DIO counts in routines in which no I/O occurs. In addition, the I/O is only updated every 10 milliseconds.
On Windows, the Synergy DBL profiler calculates elapsed CPU time according to the high‑granularity system clock. To calculate accumulated CPU time, which is only updated every 20 milliseconds, set the PROFILE_PROCESSOR_TIME environment variable. Note that on a very fast processor, accumulated CPU time results can be so imprecise as to be almost meaningless, but may be advantageous when profiling significant amounts of input or on a multi‑processor or hyperthreaded CPU.