•
Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that
read/write to hard disk are always the most expensiveoperations. Memory, if not controlled, may
have to be written to swap space onthe hard disk, which therefore increases your I/O
read/writes to disk. CPUactivity can be reduced by careful program design, and by using
commands suchas SUM (SQL) and COLLECT (ABAP/4).
•
Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead,
so that fields are only read if they are used. Thiscan make a very big difference.
•
Field-groups can be useful for multi-level sorting and displaying.However, they write their data
to the system's paging space, rather than tomemory (internal tables use memory). For this
reason, field-groups are onlyappropriate for processing large lists (e.g. over 50,000 records). If
you havelarge lists, you should work with the systems administrator to decide themaximum
amount of RAM your program should use, and from that, calculate howmuch space your lists will
use. Then you can decide whether to write the datato memory or swap space.
•
Use as many table keys as possible in the WHERE part of your selectstatements.
•
Whenever possible, design the program to access a relatively constantnumber of records (for
instance, if you only access the transactions for onemonth, then there probably will be a
reasonable range, like 1200-1800, for thenumber of transactions inputted within that month).
Then use a SELECT A B CINTO TABLE ITAB statement.
•
Get a good idea of how many records you will be accessing. Log into yourproductive system, and
use SE80 -> Dictionary Objects (press Edit), enter thetable name you want to see, and press
Display. Go To Utilities -> TableContents to query the table contents and see the number of
records. This isextremely useful in optimizing a program's memory allocation.
•
Try to make the user interface such that the program gradually unfoldsmore information to the
user, rather than giving a huge list of informationall at once to the user.
•
Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is thenumber of
records you expect to be accessing. If the number of records exceedsNUM_RECS, the data will
be kept in swap space (not memory).
•
Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all ofthe records into the
itab in one operation, rather than repeated operationsthat result from a SELECT A B C INTO
ITAB... ENDSELECT statement. Make surethat ITAB is declared with OCCURS NUM_RECS, where
NUM_RECS is the number ofrecords you expect to access.
•
If the number of records you are reading is constantly growing, you may beable to break it into
chunks of relatively constant size. For instance, if youhave to read all records from 1991 to
present, you can break it into quarters,and read all records one quarter at a time. This will
reduce I/O operations.Test extensively with GET RUN TIME when using this method.
•
Know how to use the 'collect' command. It can be very efficient.
•
Use the SELECT SINGLE command whenever possible.
•
Many tables contain totals fields (such as monthly expense totals). Usethese avoid wasting
resources by calculating a total that has already beencalculated and stored.
ABAP/4 Development Code EfficiencyGuidelines
ABAP/4 (Advanced Business Application Programming 4GL) language is an "event-driven", "top-down",
well-structured and powerful programming language.
The ABAP/4 processor controls the execution of an event. Because the ABAP/4 language incorporates
many "event" keywords and these keywords need not be in any specific order in the code, it is wise to
implement in-house ABAP/4 coding standards.
SAP-recommended customer-specific ABAP/4 development guidelines can be found in the SAP-
documentation.
This page contains some general guidelines for efficient ABAP/4 Program Development that should be
considered to improve the systems performance on the following areas:-
Physical I/O - data must be read from and written into I/O devices. This can be a potential bottle neck. A
well configured system always runs 'I/O-bound' - the performance of the I/O dictates the overall
performance.
Memory consumption of the database resources eg. buffers, etc. CPU consumption on the database and