What r the main preformence tunning things to fallow in programming..?

[Former Member]

What r the main preformence tunning things to fallow in programming..?

[Former Member]

HI

Ways of Performance Tuning

1. Selection Criteria

2. Select Statements

• Select Queries

• SQL Interface

• Aggregate Functions

• For all Entries

Select Over more than one internal table

Selection Criteria

1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.

2. Select with selection list.

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

Select Statements Select Queries

1. Avoid nested selects

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.

2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.

To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.

4. For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.

SELECT * FROM SBOOK INTO SBOOK_WA

UP TO 1 ROWS

WHERE CARRID = 'LH'.

ENDSELECT.

The above code is more optimized as compared to the code mentioned below for testing existence of a record.

SELECT * FROM SBOOK INTO SBOOK_WA

WHERE CARRID = 'LH'.

EXIT.

ENDSELECT.

5. Use Select Single if all primary key fields are supplied in the Where condition .

If all primary key fields are supplied in the Where conditions you can even use Select Single.

Select Single requires one communication with the database system, whereas Select-Endselect needs two.

Select Statements SQL Interface

1. Use column updates instead of single-row updates

to update your database tables.

SELECT * FROM SFLIGHT INTO SFLIGHT_WA.

SFLIGHT_WA-SEATSOCC =

SFLIGHT_WA-SEATSOCC - 1.

UPDATE SFLIGHT FROM SFLIGHT_WA.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

UPDATE SFLIGHT

SET SEATSOCC = SEATSOCC - 1.

2. For all frequently used Select statements, try to use an index.

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE MANDT IN ( SELECT MANDT FROM T000 )

AND CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

3. Using buffered tables improves the performance considerably.

Bypassing the buffer increases the network considerably

SELECT SINGLE * FROM T100 INTO T100_WA

BYPASSING BUFFER

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

The above mentioned code can be more optimized by using the following code

SELECT SINGLE * FROM T100 INTO T100_WA

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

Select Statements Aggregate Functions

• 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.

Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )

Consider the following extract.

Maxno = 0.

Select * from zflight where airln = ‘LF’ and cntry = ‘IN’.

Check zflight-fligh > maxno.

Maxno = zflight-fligh.

Endselect.

The above mentioned code can be much more optimized by using the following code.

Select max( fligh ) from zflight into maxno where airln = ‘LF’ and cntry = ‘IN’.

Select Statements For All Entries

• The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.

The plus

• Large amount of data

• Mixing processing and reading of data

• Fast internal reprocessing of data

• Fast

The Minus

• Difficult to program/understand

• Memory could be critical (use FREE or PACKAGE size)

Points to be must considered FOR ALL ENTRIES

• Check that data is present in the driver table

• Sorting the driver table

• Removing duplicates from the driver table

Consider the following piece of extract

Loop at int_cntry.

Select single * from zfligh into int_fligh

where cntry = int_cntry-cntry.

Append int_fligh.

Endloop.

The above mentioned can be more optimized by using the following code.

Sort int_cntry by cntry.

Delete adjacent duplicates from int_cntry.

If NOT int_cntry[] is INITIAL.

Select * from zfligh appending table int_fligh

For all entries in int_cntry

Where cntry = int_cntry-cntry.

Endif.

Select Statements Select Over more than one Internal table

1. Its better to use a views instead of nested Select statements.

SELECT * FROM DD01L INTO DD01L_WA

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

SELECT SINGLE * FROM DD01T INTO DD01T_WA

WHERE DOMNAME = DD01L_WA-DOMNAME

AND AS4LOCAL = 'A'

AND AS4VERS = DD01L_WA-AS4VERS

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

The above code can be more optimized by extracting all the data from view DD01V_WA

SELECT * FROM DD01V INTO DD01V_WA

WHERE DOMNAME LIKE 'CHAR%'

AND DDLANGUAGE = SY-LANGU.

ENDSELECT

2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

3. Instead of using nested Select loops it is often better to use subqueries.

SELECT * FROM SPFLI

INTO TABLE T_SPFLI

WHERE CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK'.

SELECT * FROM SFLIGHT AS F

INTO SFLIGHT_WA

FOR ALL ENTRIES IN T_SPFLI

WHERE SEATSOCC < F~SEATSMAX

AND CARRID = T_SPFLI-CARRID

AND CONNID = T_SPFLI-CONNID

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

The above mentioned code can be even more optimized by using subqueries instead of for all entries.

SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA

WHERE SEATSOCC < F~SEATSMAX

AND EXISTS ( SELECT * FROM SPFLI

WHERE CARRID = F~CARRID

AND CONNID = F~CONNID

AND CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK' )

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

1. Table operations should be done using explicit work areas rather than via header lines.

2. Always try to use binary search instead of linear search. But don’t forget to sort your internal table before that.

3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.

4. A binary search using secondary index takes considerably less time.

5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.

6. Modifying selected components using “ MODIFY itab …TRANSPORTING f1 f2.. “ accelerates the task of updating a line of an internal table.

Point # 2

READ TABLE ITAB INTO WA WITH KEY K = 'X‘ BINARY SEARCH.

IS MUCH FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY K = 'X'.

If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).

Point # 3

READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.

Point # 5

LOOP AT ITAB INTO WA WHERE K = 'X'.

" ...

ENDLOOP.

The above code is much faster than using

LOOP AT ITAB INTO WA.

CHECK WA-K = 'X'.

" ...

ENDLOOP.

Point # 6

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.

The above code is more optimized as compared to

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1.

7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably

8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.

9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to “ LOOP-APPEND-ENDLOOP.”

10. “DELETE ADJACENT DUPLICATES“ accelerates the task of deleting duplicate entries considerably as compared to “ READ-LOOP-DELETE-ENDLOOP”.

11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to “ DO -DELETE-ENDDO”.

Point # 7

Modifying selected components only makes the program faster as compared to Modifying all lines completely.

e.g,

LOOP AT ITAB ASSIGNING <WA>.

I = SY-TABIX MOD 2.

IF I = 0.

<WA>-FLAG = 'X'.

ENDIF.

ENDLOOP.

The above code works faster as compared to

LOOP AT ITAB INTO WA.

I = SY-TABIX MOD 2.

IF I = 0.

WA-FLAG = 'X'.

MODIFY ITAB FROM WA.

ENDIF.

ENDLOOP.

Point # 8

LOOP AT ITAB1 INTO WA1.

READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.

IF SY-SUBRC = 0.

ADD: WA1-VAL1 TO WA2-VAL1,

WA1-VAL2 TO WA2-VAL2.

MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.

ELSE.

INSERT WA1 INTO ITAB2 INDEX SY-TABIX.

ENDIF.

ENDLOOP.

The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by

LOOP AT ITAB1 INTO WA.

COLLECT WA INTO ITAB2.

ENDLOOP.

SORT ITAB2 BY K.

COLLECT, however, uses a hash algorithm and is therefore independent

of the number of entries (i.e. O(1)) .

Point # 9

APPEND LINES OF ITAB1 TO ITAB2.

This is more optimized as compared to

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

Point # 10

DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.

This is much more optimized as compared to

READ TABLE ITAB INDEX 1 INTO PREV_LINE.

LOOP AT ITAB FROM 2 INTO WA.

IF WA = PREV_LINE.

DELETE ITAB.

ELSE.

PREV_LINE = WA.

ENDIF.

ENDLOOP.

Point # 11

DELETE ITAB FROM 450 TO 550.

This is much more optimized as compared to

DO 101 TIMES.

DELETE ITAB INDEX 450.

ENDDO.

12. Copying internal tables by using “ITAB2[ ] = ITAB1[ ]” as compared to “LOOP-APPEND-ENDLOOP”.

13. Specify the sort key as restrictively as possible to run the program faster.

Point # 12

ITAB2[] = ITAB1[].

This is much more optimized as compared to

REFRESH ITAB2.

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

Point # 13

“SORT ITAB BY K.” makes the program runs faster as compared to “SORT ITAB.”

Internal Tables contd…

Hashed and Sorted tables

1. For single read access hashed tables are more optimized as compared to sorted tables.

2. For partial sequential access sorted tables are more optimized as compared to hashed tables

Hashed And Sorted Tables

Point # 1

Consider the following example where HTAB is a hashed table and STAB is a sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE HTAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

This runs faster for single read access as compared to the following same code for sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE STAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

Point # 2

Similarly for Partial Sequential access the STAB runs faster as compared to HTAB

LOOP AT STAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

This runs faster as compared to

LOOP AT HTAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

<b>Reward if usefull</b>

[matt]

The most serious performance issues with programs relate usually to the algorithm. If the duration or program increases exponentially with data volumes, then any optimisations will soon be swamped. I.e. if with 1MB of data the program takes 2 minute, with 2MB it takes 4, with 3 MB it takes 8, and, generally, with nMB it takes 2^n minutes.

Note that this kind of issue can arise with using, e.g. STANDARD TABLES, rather than HASHED TABLES.

matt

[former_member194613]

The most serious performance problems are actually poor database selects.

If there is no proper index support for a select then the statement can take even minutes to be processed. This becomes especially serious with joins.

The other really serious problem is nonlinear coding, it data increases by a fac tor of 10 then a 10-times longer runtime is often not avoidable. Nonlinear coding means that the runtime does not only increase by a factor of 10 but by a factor of 100.

Nonlinear coding arises already from simple nested loops:

loop at itab1
  read itab2 with key
endloop

if itab2 does not use binary search or a sorted or a hashed table and if itab1 and itab2 grow when you process larger objects.

These 2 types of problems can make your program by factors slower.

All other tuning have usually effects in percentages. They are also important, but they will overshadowed if there are problems of these 2 types in the program.

Siegfried

[matt]

OK Siegfried - you put it better than I did! btw - technically we should talk about non-polynomial, rather than non-linear.

If a well written program's duration is proportional to the square of the data volumes, that is not considered, generally, to be an algorithmic issue. If the duration is proportional to 2 to the power of the data volumes, it is.

In the former

1 - 2, 2 - 4, 3 - 9, 4 - 16, 5 - 25, 6 - 36, 7 - 49,...

In the latter

1 - 2, 2 - 4, 3 - 8, 4 - 16, 5 - 32, 6 - 64, 7 -128,...

Cheers

matt

[ThomasZloch]

The single most serious performance problem is having to read the ever same questions again and again...can you not check wether this has been asked and answered before? (it has, about 2,000 times...)

please reward if painful

[former_member194613]

> OK Siegfried - you put it better than I did! btw - technically we should talk about

> non-polynomial, rather than non-linear.

not really, actually I mean nonlinear, i.e. quadratic and cubic behavior is not acceptable.

In theoretical computer science nonlinear coding might be o.k., but in business transactions it is not. It is actually not necessary to have quadratic coding. There are only a few optimization tasks where it is really necessary, they should be handled as exceptions.

However, if you do test, you will encounter quadratic coding in most programs which not been tested before, and you will see that in 95% it is possible to change the coding into linear coding (actually linear times log).

For more information on that topix see my blog

Nonlinearity: The problem and background

/people/siegfried.boes/blog/2007/02/12/performance-problems-caused-by-nonlinear-coding

Siegfried

[matt]

<i>However, if you do test, you will encounter quadratic coding in most programs which not been tested before, and you will see that in 95% it is possible to change the coding into linear coding (actually linear times log).</i>

With any Polynomial algorithm, you can optimise statements, buy faster disks and processors, and, as you say, in most cases you can reduce to linear.ln. But with exponential, all bets off. The runtime will always eventually increase beyond the abilities of the software and hardware.

In those terms, I'd refer to the problem being P/NP, rather than non-linear. Though I'll completely agree that, e.g. quintic programming will be an issue. In practice, the highest I've ever encountered, and that rarely, is quadratic. When you really are churning out every combination.

matt

[ThomasZloch]

good to see that a boring question can lead to interesting discussions.

Of course the repetitive paste job got the points, but what the heck

[Former Member]

hi,

Avoid using SELECT...ENDSELECT... construct and use SELECT ... INTO TABLE.

Use WHERE clause in your SELECT statement to restrict the volume of data retrieved.

Design your Query to Use as much index fields as possible from left to right in your WHERE statement

Use FOR ALL ENTRIES in your SELECT statement to retrieve the matching records at one shot.

Avoid using nested SELECT statement, SELECT within LOOPs.

Avoid using INTO CORRESPONDING FIELDS OF TABLE. Instead use INTO TABLE.

Avoid using SELECT * and Select only the required fields from the table.

Avoid nested loops when working with large internal tables.

Use assign instead of into in LOOPs for table types with large work areas

When in doubt call transaction SE30 and use the examples and check your code

Whenever using READ TABLE use BINARY SEARCH addition to speed up the search. Be sure to sort the internal table before binary search. This is a general thumb rule but typically if you are sure that the data in internal table is less than 200 entries you need not do SORT and use BINARY SEARCH since this is an overhead in performance.

Use "CHECK" instead of IF/ENDIF whenever possible.

Use "CASE" instead of IF/ENDIF whenever possible.

Use "MOVE" with individual variable/field moves instead of "MOVE-CORRESPONDING", creates more coding but is more effcient.

TABLE BUFFERING : This can help in improving the performance but this has to be used with caution. Buffering of tables leads to data being read from the buffer rather than from table. Buffer sync with table happens periodically. If this table is a transaction table chances are that the data is changing for a particular selection criteria. Using table buffering in such cases is not recommended. Use Table Buffering for Master Data or data which is having low transaction. Also, when using a table with buffering ensure that the general criteria which is used for buffering is also being used. If the criteria of buffering is not same as the one used in your code, it has no effect and buffering will not be useful instead it will cause a overhead on performance since evrytime it will fill the buffer. In such cases use 'BYPASSING BUFFER' to speed up the SQL's.

INDEX: Creation of Index for improving performance should not be taken without thought. Index speeds up the performance but at the same time adds two overheads namely; memory and insert/append performance. When INDEX is created, memory is used up for storing the index and index sizes can be quite big on large transaction tables! When inserting new entry in the table, all the index's are updated. More index more time. More the amount of data, bigger the indices, larger the time for updating all the indices.

PERFORM : When writing a subroutine, always provide type for all the paramters. This reduces the overhead which is present when system determines on it's own each type from the formal parameters that are passed.

Updating/Modifying internal tables: In case the amount of entries are more than 200 in an internal table and some field's are being manipulated or some column of the internal table being filled based on some logic, usage of FIELD-SYMBOLS is recommended. This removes the overhead of moving the operation via a seperate memory area (work area).