home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / PROG_GEN / MFCOBOPT.ZIP / OPTIMIZE.DOC
Text File  |  1994-02-26  |  13KB  |  338 lines
  1.   ==========================================================================
  2.                  M I C R O   F O C U S   C O B O L / 2
  3.  
  4.                                 V 2.5.25
  5.   ==========================================================================
  6.  
  7.                        CREATING OPTIMIZED PROGRAMS
  8.                        ===========================
  9.  
  10.   This document should be regarded as a supplement to the chapter Writing
  11.   Programs in your Operating Guide. It gives some guidelines which, if
  12.   followed, allow your COBOL system to optimize fully the native code
  13.   produced for your programs - resulting in smaller and faster applications.
  14.  
  15.  
  16.   TABLE OF CONTENTS
  17.  
  18.       INTRODUCTION
  19.       DATA DIVISION CONSIDERATIONS
  20.           Data Types
  21.           Linkage Items
  22.           Large Data Divisions
  23.       PROCEDURE DIVISION CONSIDERATIONS
  24.           Arithmetic Statements
  25.           Alphanumeric Data Manipulation
  26.           Tables
  27.           Conditional Statements
  28.           Loops and Subroutines
  29.           CALL statements
  30.           Large Procedure Divisions
  31.       COMPILER DIRECTIVES
  32.       EXAMINING THE NATIVE CODE
  33.  
  34.  
  35.   INTRODUCTION
  36.  
  37.   The guidelines are set out in a "Do this" / "Don't do that" style. Do
  38.   remember that these are only guidelines; programs that do not conform to
  39.   these guidelines will still run correctly, just less efficiently.
  40.  
  41.   For further information on many of the topics discussed in this document,
  42.   see chapter Compiling and chapter Writing Programs in your Operating
  43.   Guide.
  44.  
  45.  
  46.   DATA DIVISION CONSIDERATIONS
  47.  
  48.   Data Types
  49.   ----------
  50.    o  Use unsigned COMP-5 or COMP-X numeric data items; preferably COMP-5.
  51.  
  52.    o  Use 2-byte COMP-5 items rather than single byte fields for arithmetic.
  53.  
  54.    o  Do not use numeric items that occupy more than 4 bytes of storage.
  55.  
  56.    o  Do not redefine COMP-5 items to access individual bytes; if access to
  57.       individual bytes is required use COMP-X.
  58.  
  59.    o  Use edited items only when necessary and use only simple ones such as
  60.       ZZ9. If possible use them in a subroutine so the total number of
  61.       edited moves in your program is kept as small as possible.
  62.  
  63.    o  Do not use items defined as EXTERNAL.
  64.  
  65.    o  Align items on even byte boundaries and ensure the stride of a table
  66.       is an even number, if possible a power of 2 (pad the table as
  67.       necessary). The stride of a table is the size of one element; for
  68.       example, the stride of the following table is 2 bytes:
  69.  
  70.       01 a occurs 10.
  71.           05 b pic x
  72.           05 c pic x.
  73.  
  74.  
  75.   Linkage Items
  76.   -------------
  77.    o  Don't make many references to items defined in the Linkage Section
  78.       (examples: linkage parameters; x"D0" allocated memory). It is more
  79.       efficient to move the data to Working-Storage, manipulate it there,
  80.       then move it back again.
  81.  
  82.    o  If a parameter is optional you can detect its presence  using the
  83.       following syntax:
  84.  
  85.       IF ADDRESS OF linkage-item NOT = NULL
  86.  
  87.  
  88.   Large Data Divisions
  89.   --------------------
  90.    o  Ensure the size of your Data Division is less than 64 kilobytes (64K),
  91.       keeping the total size as small as possible. In the Procedure Division
  92.       the RTS can swap segments, but it cannot page the Data Division.
  93.  
  94.    o  Redefine memory that is only used during certain phases of a program's
  95.       execution so that it can be shared by several routines.
  96.  
  97.    o  If more than 64K of data is required use a heap, or use the x"D0"
  98.       COBOL System Library Routine to allocate the space dynamically. But
  99.       remember x"D0" items have the disadvantage of being Linkage items.
  100.  
  101.    o  Do not use the NOSMALLDD directive unless you have no choice. If
  102.       necessary (normally for parameters passed to your program by external
  103.       programs), use the SEGCROSS directive so that the performance of most
  104.       data accesses is not affected.
  105.  
  106.  
  107.   PROCEDURE DIVISION CONSIDERATIONS
  108.  
  109.   Arithmetic Statements
  110.   ---------------------
  111.    o  Use simple forms (for example, ADD a TO b) of the arithmetic verbs and
  112.       do not use the COMPUTE verb.
  113.  
  114.    o  Do not use the GIVING form of these verbs. If necessary create
  115.       temporary variables and code several simple statements to achieve the
  116.       same result. For example, write:
  117.  
  118.           MOVE a TO c
  119.           ADD  b TO c
  120.  
  121.       rather than:
  122.  
  123.           ADD a TO b giving c
  124.  
  125.    o  Do not mix items of different sizes in an arithmetic statement (for
  126.       example, try to use all 2-byte items or all 4-byte items).
  127.  
  128.    o  Do not use the REMAINDER, ROUNDED, ON SIZE ERROR or CORRESPONDING
  129.       phrases.
  130.  
  131.  
  132.   Alphanumeric Data Manipulation
  133.   ------------------------------
  134.    o  Reference modified fields are optimized if coded in one of the
  135.       following forms:
  136.  
  137.       item (literal:)
  138.       item (literal:literal)
  139.       item (literal:variable)
  140.       item (variable:variable)
  141.       item (variable + literal:literal)
  142.       item (variable - literal:literal)
  143.       item (variable + literal:variable)
  144.       item (variable - literal:variable)
  145.  
  146.       Other forms of reference modification are inefficient.
  147.  
  148.    o  If the offset or length of the reference modification is a data item,
  149.       use a 2-byte COMP-5 item. Define it in Working-Storage.
  150.  
  151.    o  In a MOVE statement, have the source item the same size as or larger
  152.       than the target. This prevents space-padding code being generated.
  153.  
  154.    o  Do not use the INITIALIZE verb.
  155.  
  156.    o  Do not use the CORRESPONDING option of the MOVE verb.
  157.  
  158.    o  Do not use the STRING or UNSTRING verbs - they create a lot of code.
  159.       For manipulating filenames use the COBOL System Library Routines
  160.       CBL_SPLIT_FILENAME and CBL_JOIN_FILENAME. For other purposes, create
  161.       your own loops; they will almost always be more efficient.
  162.  
  163.  
  164.   Tables
  165.   ------
  166.    o  The optimal definition for a subscript is a 2-byte COMP-5 item.
  167.  
  168.    o  Subscripts for items that have the same stride and are used in
  169.       consecutive statements are optimized so that they are only evaluated
  170.       once. For example:
  171.  
  172.           01 A PIC XX OCCURS 10.
  173.           01 B PIC XX OCCURS 10.
  174.           01 C PIC XX OCCURS 10.
  175.           01 D PIC XX OCCURS 10.
  176.               . . .
  177.               MOVE A(I) TO B(I)
  178.               IF C(I) = D(I)
  179.                   DISPLAY "PASS"
  180.               END-IF
  181.  
  182.       would result in the subscript I being evaluated only once, although it
  183.       is used four times in two statements.
  184.  
  185.    o  When compiling your program for use in production, use the NOBOUND
  186.       directive so that subscript range checking code is not included. Use
  187.       BOUND only when debugging.
  188.  
  189.  
  190.   Conditional Statements
  191.   ----------------------
  192.    o  Do not use large EVALUATE statements. They are compiled into a series
  193.       of IF ... ELSE IF ... statements where the value of the expression is
  194.       derived separately for each WHEN clause.
  195.  
  196.    o  Order an EVALUATE statement so that the most commonly satisfied
  197.       condition is tried first. Do not use complex expressions or Linkage
  198.       items as conditions in an EVALUATE statement; instead, calculate the
  199.       value yourself in a Working-Storage item and use that item.
  200.  
  201.    o  Comparing for equality or inequality is more efficient than testing
  202.       for "greater than" or "less than", especially with COMP-X or
  203.       alphanumeric items.
  204.  
  205.    o  In both alphanumeric and numeric comparisons, have the source and
  206.       target items the same size.
  207.  
  208.    o  Use a GO TO ... DEPENDING statement if the range of possible values is
  209.       fairly close. Although this construct has the disadvanage of not being
  210.       particularly suited to structured programming, it is efficient.
  211.  
  212.  
  213.    Loops and Subroutines
  214.    ---------------------
  215.    o  When incrementing or decrementing a counter, terminate it with a
  216.       literal value rather than a value held in a data item. For example, to
  217.       execute a loop n times, set the counter to n and then decrement the
  218.       counter until it becomes zero, rather than incrementing the counter
  219.       from 0 to n.
  220.  
  221.    o  The range of an out-of-line PERFORM statement should not contain the
  222.       end of another perform range. (One way to ensure this is to perform
  223.       sections only, not paragraphs; however, with carefully structured
  224.       programming this should not arise). You can then compile your program
  225.       with the generator directive NOTRICKLE, which lets the compiler
  226.       produce more efficient code. This coding style generally gives you a
  227.       more easily maintained program too.
  228.  
  229.    o  Do not use PERFORM a THRU b as this too can lead to trickling code.
  230.  
  231.    o  Use PERFORM para N TIMES but not the equivalent in-line perform.
  232.  
  233.    o  Put commonly used pieces of code in sections or paragraphs and PERFORM
  234.       them. This is saves space for any statement used more than once that
  235.       produces more than 4 bytes of generated code (in a NOTRICKLE program).
  236.       It is often beneficial even on single statements, for example edited
  237.       moves, subprogram calls or file I/O.
  238.  
  239.  
  240.   CALL statements
  241.   ---------------
  242.    o  Try to limit the number of CALL statements a program makes, if
  243.       necessary by avoiding splitting it into too many subprograms.
  244.  
  245.    o  CALL statements that do not alter the RETURN-CODE special register or
  246.       whose effect on RETURN-CODE are of no interest should use a calling
  247.       convention of 4 (the checker directive DEFAULTCALLS can be used to set
  248.       this globally).
  249.  
  250.    o  Calls to the COBOL System Library Routines that carry out logical
  251.       operations (CBL_AND, etc) are optimized by the generator to actual
  252.       machine logical operations, providing the parameters are 8 bytes long
  253.       or less. These too should use a calling convention of 4.
  254.  
  255.    o  Use the generator directive NOPARAMCOUNTCHECK if your program is
  256.       always called with the correct number of parameters, or if it does not
  257.       reference unsupplied parameters. Most programs will fall into this
  258.       category.
  259.  
  260.  
  261.   Large Procedure Divisions
  262.   -------------------------
  263.    o  On DOS or OS/2, code segments are limited in size to 64K. Do not let
  264.       the generator decide where to break your program into segments.
  265.       Instead segment the program manually, that is, by using the segment
  266.       number on a section header, so you can choose where to split it. Avoid
  267.       inter-segment PERFORM and GO TO statements.
  268.  
  269.    o  If appropriate the memory needed can be reduced by manually segmenting
  270.       a procedure division smaller than 64K. As the RTS can segment-swap
  271.       procedural code this is rarely necessary.
  272.  
  273.  
  274.   DIRECTIVES
  275.  
  276.   A number of checker and generator directives can be used to enable the
  277.   native code for a program to be better optimized. Some of these directives
  278.   must be used with care; ensure that the behavior that you get with these
  279.   directives is acceptable.
  280.  
  281.   Use the following directives when checking and generating your programs:
  282.  
  283.        NOALTER
  284.        ALIGN(2)
  285.        NONESTCALL
  286.        OPTSIZE
  287.  
  288.    Use with care:
  289.  
  290.        NOTRICKLE
  291.        DEFAULTCALLS(4)
  292.        NOPARAMCOUNTCHECK
  293.  
  294.    Use when compiling for production:
  295.  
  296.        NOANIM
  297.        NOBOUND
  298.  
  299.    Other suggestions (to help prevent inefficient coding):
  300.  
  301.        REMOVE "UNSTRING"
  302.        REMOVE "STRING"
  303.        REMOVE "GIVING"
  304.        REMOVE "ROUNDED"
  305.        REMOVE "COMPUTE"
  306.        REMOVE "ERROR"
  307.        REMOVE "ALTER"
  308.        REMOVE "INITIALIZE"
  309.        REMOVE "CORRESPONDING"
  310.        REMOVE "TALLYING"
  311.        REMOVE "THRU"
  312.        REMOVE "THROUGH"
  313.  
  314.  
  315.   EXAMINING THE NATIVE CODE
  316.  
  317.   You can see the generated code produced for your program, by using the
  318.   generator directives ASMLIST() SOURCEASM to produce a .GRP file containing
  319.   the assembler and source listing in the same file.
  320.  
  321.   If the generator considers a statement for optimization, but finds that it
  322.   does not conform to the necessary guidelines, the word "BADCODE" appears
  323.   next to the statement, on the right-hand side of the listing. But some
  324.   statements that have generated inefficient code will not have been
  325.   identified in this way; you can usually spot these by looking for a single
  326.   statement that has generated a lot of assembler code.
  327.  
  328.   Try to eliminate or at least reduce the inefficient statements in your
  329.   program. But be aware of the law of diminishing returns; as you improve
  330.   the efficiency of your program, you will eventually reach a point where a
  331.   lot of extra effort will give only small further gains.
  332.  
  333.   ==========================================================================
  334.   Micro Focus is a registered trademark of Micro Focus Limited.
  335.   Micro Focus COBOL/2 is a trademark of Micro Focus Limited.
  336.   ==========================================================================
  337.   Copyright (C) 1991 Micro Focus Ltd     Vrn/OPTIMIZE.DOC/2.5.01/28Mar91/nrV
  338.