HP 3000 Manuals

HP SPT/XL User's Manual: Analysis Software

About Program Tuning 

Typical goals of program tuning with HP SPT/XL include:

 *  Ensuring that programs use resources efficiently.

 *  Maximizing overall transaction throughput.

 *  Optimizing user transaction response for consistency.

In addition, achieving acceptable performance always includes appropriate
hardware configuration and load-management practices.

HP SPT/XL helps you identify the areas of application code or data or
both that would most benefit from optimization tuning efforts.

Profiling a program with HP SPT/XL is an iterative process of focusing in
on where optimization efforts will give you the most payback in terms of
performance.

As figure 1-1 shows, you focus in by going from the overall program level
to a specific intrinsic within the dominant transaction.  You identify
the dominant transaction, or intrinsic, or file by looking at system
resource use.


          Figure 1-1.  Profiling an Application Program with HP SPT/XL 

You can profile a program's behavior at several stages of its life cycle.
During prototype development, profiling helps you verify that the program
meets design goals.  During development, it helps characterize the
performance of added functions.  In a production environment, it provides
data for deciding where to assign performance-tuning effort.

Whenever profiling takes place in the program's life cycle, it lets you
know whether transaction performance is consistent.  It also tells you if
overall throughput is limited by available processing capacity, main
memory capacity, disk I/O capability, or contention for software
resources.

Program Structure 

There are two layers of code in which a program can spend its time--the
user's application code and the system code.

A program can be coded to process many types of transactions.
Application code can consist of any program files and executable
libraries generated by the native language compilers available for
MPE-XL--for example, COBOL II/XL, Pascal/XL, FORTRAN 77/XL, and C/XL. For
programs written in interpretive languages (such as Transact/XL) the
language interpreter program itself is the application layer.

Similarly, system code can be made up of procedures that are directly
callable by application code, as well as those that are internal to the
subsystem or operating system.  This might include TurboIMAGE, VPLUS, and
Network Services.  This code is contained in the executable libraries
XL.PUB.SYS and NL.PUB.SYS.


          Figure 1-2.  Program Structure 

System Code Dominant Programs.  System code dominant programs spend most
of their processing time--up to 99%--in system code, and the rest of the
time in application code.  Native mode MPE XL services make up the bulk
of system code used in these programs.  Much of the code used by
interactive programs is associated with terminal I/O. Both interactive
and batch programs use much code associated with information storage and
retrieval.

Most MPE-based programs are in this category because of the predominance
of commercial applications in MPE environments and the common reliance on
KSAM and TurboIMAGE for information management.

Programs in this category can use any of the native MPE XL
languages--usually COBOL and Pascal or interpretive fourth generation
(4GL) languages.

To tune a program in this category you must optimize the method and
frequency with which the program invokes system code.  Data file
structure and loading characteristics must also be considered when tuning
such programs.

Application Code Dominant Programs.  Application code dominant programs
spend most of their time doing numeric computation in application code;
little time is spent in system code.

This category includes statistical analysis or formula-intensive
programs, typically written in FORTRAN, Pascal, or C. They are the
exception in MPE environments.

To tune these programs you must identify the program procedures consuming
the most processor resource and refine its coding algorithms.  Using more
efficient language syntax within program procedures is also a
consideration, although this tends to be host-specific and impractical if
source code portability is needed.

MPE/iX 5.0 Documentation