If Condition
When coding IF tests, nest the testing conditions so that
the outer conditions are those which are most frequently true. This will
ensure minimal code execution. Similarly, for logical expressions with
‘AND’, place the most likely false first and for the OR, place the most
likely true first.
Case Statement
When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.
This feature is also available in SAP Tips & Tricks. As can be seen the time measured for the same logical units of code using if… elseif … endif is almost twice that of case … endcase.
It is always advisable to use case … endcase as far as possible.
Note: CASE statement used in place of IF where field checked
for > 2 values.
Describe Statement
DESCRIBE TABLE <itable> [LINES <l>] [OCCURS <n>]
[KIND <k>]
To find out how many entries are in an internal table use DESCRIBE.
DESCRIBE TABLE ITAB LINES CNTLNS.
Is more efficient than
LOOP AT ITAB.
CNTLNS = CNTLNS + 1.
ENDLOOP.
Type Conversions
The processor takes additional time to convert from one
data type to another.
Type ‘P’ fields
Unless rounding errors are not avoidable, do not use ‘packed’
data variables.
Field Length
To find out the length of a field use the string length function.
FLDLEN = STRLEN (FLD).
Is more efficient than
IF FLD CP ‘* #’.
ENDIF.
FLDLEN = SY-FDPOS.
Arithmetic Operators
Use symbols for arithmetic operators instead of characters for better performance.
Example : use <> instead of ne .
Use of tables
Internal tables vs. field groups:
Using internal tables is more efficient than field groups and should be used when possible.
If the volume of data is very much, field groups are more
efficient compared to internal
tables in terms of memory management.
ASSIGN
Use of field symbols is discouraged unless necessity dictates.
Field symbols, when used, should be documented in program comments when
defined and whenever used. Always have a type declaration for field symbols.
AT PFnn
Use the ‘AT USER COMMAND’ instead of ‘AT PFnn’. This ensures
proper response to the user command and is more legible.
CHECK
Use check statements whenever possible instead of nested
IF’s.
User Interface (GUI)
GUI statuses should be used for interactive
report programs and online programs. Use menu bar linking whenever
possible to build consistent GUI statuses for screens within a module pool.
CHECK, EXIT, REJECT, STOP & CONTINUE
Use these statements to suspend processing and/or skip
remaining unnecessary processing for improved
performance.
Subroutines
Whenever values need to be passed in a subroutine have type declarations assigned to the formal parameters. If no specific type declaration is possible then use TYPE ANY. This improves the performance. It is also recommended by SAP and can be noticed during extended program check (EPC) for the program.
E.g. Do not use the following statement:-
perform type_test using p_var1 p_var2 p_var3.
---
form type_test using p_var1 p_var2 p_var3.
---
endform.
Instead use the following statement:-
perform type_test using p_var1 p_var2 p_var3.
---
form type_test using p_var1 type c
p_var2 type any
p_var3 like mara-matnr.
---
endform.
When modularizing your program, use FORMS rather than FUNCTIONS whenever practical. A statement of PERFORM FORM <..> requires significantly less resources and time than does a CALL FUNCTION <..>.
Field-Symbols
This is similar to type declarations for subroutines. Except that type declarations need to be maintained for field-symbols.
E.g. Do not use the following statement:-
field-symbols: <fs1>, <fs2>, <fs3>.
Instead use the following statement:-
field-symbols: <fs1> type c,
<fs2> like mara-matnr,
<fs3> like marc-werks.
