Since your web browser does not support JavaScript,
here is a non-JavaScript version of the image slideshow:
Always
specify your conditions in the Where-clause instead of checking them yourself
with check statements. The database system can then use an index (if possible)
and the network load is considerably less .
For
all frequently used Select statements, try to use an index. You always use an
index if you specify (a generic part of) the index fields concatenated with
logical Ands in the Select statement's Where clause. Note that complex Where
clauses are poison for the statement optimizer in any database system.
If
there exists at least one row of a database table or view with a certain condition,
use the Select Single statement instead of a Select-Endselect-loop. Select Single
requires one communication with the database system, whereas Select-Endselect
needs two.
It
is always faster to use the Into Table version of a Select statement than to
use Append statements.
To
read data from several logically connected tables use a join instead of nested
Select statements. Network load is considerably less.
If
you want to find the maximum, minimum, sum and average value or the count of
a database column, use a select list with aggregate functions instead of computing
the aggregates yourself. Network load is considerably less.
If
you process your data only once, use a Select-Endselect-loop instead of collecting
data in an internal table with Select Into Table. Internal table handling takes
up much more space.
Use
a select list or a view instead of Select * , if you are only interested in
specific columns of the table. Network load is considerably less.
For
all frequently used, read-only tables, try to use SAP buffering. Network load
is considerably less.
Whenever
possible, use array operations instead of single-row operations to modify your
database tables. Frequent communication between the application program and
database system produces considerable overhead.
Whenever
possible, use column updates instead of single-row updates to update your database
tables. Network load is considerably less.
Instead
of using nested Select loops or FOR ALL ENTRIES it is often possible to use
subqueries. Network load is considerably less.
Use
the special operators CO, CA, CS, instead of programming the operations yourself.
If ABAP/4 statements are executed per character on long strings, CPU consumption
can rise substantially.
Some
function modules for string manipulation have become obsolete and should be
replaced by ABAP/4 statements or functions: STRING_CONCATENATE... -> CONCATENATE,
STRING_SPLIT... -> SPLIT, STRING_LENGTH -> strlen(), STRING_CENTER -> WRITE...TO...CENTERED,
STRING_MOVE_RIGHT -> WRITE...TO...RIGHT-JUSTIFIED
Use
the CONCATENATE statement instead of programming a string concatenation of your
own.
If
you want to delete the leading spaces in a string, use the ABAP/4 statement
SHIFT...LEFT DELETING LEADING... .Other constructions (with CN and SHIFT...BY
SY-FDPOS PLACES, with CONDENSE if possible, with CN and ASSIGN CLA+SY-FDPOS(LEN)
...) are not as fast. In any case, avoid using SHIFT inside a WHILE-loop!
Use
the SPLIT statement instead of programming a string split yourself.
Use
the strlen( ) function to restrict the DO loop to the relevant part of the field,
e.g. when determinating a check-sum.
Use
"CLEAR f WITH val" whenever you want to initialize a field with a value different
from the field's type-specific initial value.
Try
to keep the table ordered and use binary search or used a table of type SORTED
TABLE. If TAB has n entries, linear search runs in O( n ) time, whereas binary
search takes only O( log2( n ) ).
A
dynamic key access is slower than a static one, since the key specification
must be evaluated at runtime. However, for large tables the costs are dominated
by number of comparison needed to locate the entry.
If
you need to access an internal table with different keys repeatedly, keep your
own secondary indices.With a secondary index, you can replace a linear search
with a binary search plus an index access.
LOOP
... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified
condition internally. As with any logical expressions, the performance is better
if the operands of a comparison share a common type. The performance can be
further enhanced if LOOP ... WHERE is combined with FROM i1 and/or TO i2, if
possible.