Suggested tips for improving an application's performance

Date: Archived
Product/Release: LANSA for the AS/400
Abstract: Tips for improving application performance
Submitted By: LANSA Technical Support

Using I/O modules in large systems with lots of tables can have a heavy performance overhead. *DBOPTIMISE was introduced to help reduce this overhead. This overhead can be taken to within 20% of hand written RPG programs (as long as the RPG programs are doing the same work). Some points for reducing overhead are:

  • The use of I/O modules may be slow because OS/400 is slow at handling calls between programs. Using *DBOPTIMISE and *DBOPTIMISE_BATCH is recommended to reduce this overhead, particularly in heavily used applications. The use of *DBOPTIMISE and *DBOPTIMISE_BATCH gives a very substantial performance improvement
  • If *DBOPTIMISE is being used, make sure files use SHARE(*YES) to save unnecessary file OPENs.
  • Using *DBOPTIMISE does NOT affect the conceptual integrity of separating rules and functions, it just means that more compiles are required when something is changed and it very substantially improves performance
  • Use High Speed Tables. Using High Speed Tables is about 50% faster than hand written RPG
  • Compiling functions without DEBUG capability marginally improves performance.
  • Using *MLOPTIMISE improves performance by removing an extra call at each function's invocation. This is especially important in functions that are called to act as "subroutines"
  • Using a non-multilingual partition will improve performance
  • Use a multilingual partition with only ONE language defined. If only one language is defined in a partition, applications in that partition will have the same performance as non-multilingual applications as long as *MLOPTIMISE is used in all functions
  • Call functions using *DIRECT instead of going through the process definition. This will save an extra call to the process program and it is much more efficient
  • Use the KEEP_LAST parameter on FETCH commands to save I/Os
  • Use *HEAVYUSAGE in suitable situations. (do not overuse though because this option may cause PAG (Process Access Group) space problems
  • Use *NOMESSAGES whenever possible, especially in heavy called functions that act as "subroutines"
  • Avoid using EXCHANGE with many fields. When many field values need to be passed (more than 10) or the function is called many times use PASS_DS and PASS_LST for better performance
  • LANSA programmers should read the "Application Performance" section in the Tips and Techniques guide. This section has information on many areas including:
    • Interactive, batch and overnight processing
    • Using KEEP_LAST with FETCH
    • Keeping files open
    • Using *DBOPTIMISE
    • Setting security flags
    • Estimating a function's resource utilization (ERUF)
  • Long compile time are almost always related to large functions. A large function is anything over 250 lines It may seem obvious, but it is worth pointing out

    If a 20 line function takes 1 minute to compile
    then a 200 line function may take 10 minutes to compile
    and a 2000 line function may take 100 minutes to compile

Often this very simple line progression is not obvious to programmers who make bigger and bigger functions

  • A separate subsystem with its own memory pool should be used for compiles to minimize affecting other subsystems/users
  • Running more than 1 or 2 active compilation jobs at the same time is not recommended. The more jobs active, the more work OS/400 has to do to swap between them
  • If online full function checks are used, these will use a lot of CPU cycles so the batch compiles will not have a chance to run quickly
  • An option exists to submit compiles from the RDML editor when a full function check ends successfully. The use of this option will make compiles faster because a full function check will not have to be done in batch. This option is available from the function editor in PC G3
  • Function compiles will run marginally faster if they are not enabled for DEBUG
  • Function compiles will run faster if *MLOPTIMISE is used
  • Function compiles from a non-multilingual partition will run faster
  • Function compiles from a multilingual partition that only has ONE language will run faster
  • Think about using LANSA/PC to offload definition, FFCs and screen/report painting to the PC
  • Think about using LANSA/PCX to offload compile/testing to the PC

Summary of things to check

  1. Consistently large programs (greater than 100 lines)
    Overlay complex for little gain
    Calculate "ERUF" figures
  2. Writing/designing RPG in LANSA. This is the most likely cause of
    Large programs
    Long development time that is comparable to RPG
  3. Advanced design/using LANSA features to minimize coding
    Use of dictionary rules
    F4=Prompt handling
    Triggers
  4. Use of performance options
    ONE language in multilingual partition
    *DBOPTIMISE and *DBOPTIMISE_BATCH
    *NOMESSAGES, KEEP_LAST, *DIRECT, PASS_DS/PASS_LST, *MLOPTIMISE