performance

[Former Member]

how to improve performance of a program?

[Former Member]

Hi,

SQL Trace

Use

The SQL Trace function is an on-demand log of selected SQL statements that are issued against the database through the Open SQL Engine. The SQL Trace can be switched on or off dynamically. The log format is database independent. Besides the SQL statement text, each log record contains information about the point in time when the statement was executed, its duration, its input parameters and results (where applicable) as well as context information.

Features

The SQL Trace is especially useful for:

· Development

SQL Trace can help JDO, enterprise beans, servlet and JSP developers to learn which kind of database accesses their code produces.

· Performance analysis

Typically, performance issues are caused by inefficient database accesses. In this case SQL Trace can be used to show the issued SQL statements and their duration, thus helping to identify inefficient SQL statements.

SQL Trace Analysis

The SQL Trace part of the Performance Trace tool allows you to see how the OPEN SQL statements that you use in ABAP programs are converted to standard SQL statements (see Embedded SQL) and the parameters with which the embedded SQL statements are passed to the database system.

Overview

While the trace is switched on, the SQL Trace function records all database activity by a particular user or group of users. The R/3 System takes OPEN SQL statements and converts them in to embedded SQL statements that it passes to the database. It is the embedded SQL statements, their parameters, return codes, and the number of entries retrieved, inserted, or deleted that are recorded in the SQL Trace file. The log file also contains the runtime of the statement and the place in the application program from which it was called.

The SQL trace tells you:

The SQL statements executed by your program.

The values that the system uses for particular database access and changes.

How the system converts ABAP Open SQL statements (such as SELECT) into Standard SQL statements.

Where your application executes COMMITs.

Where your application repeats the same database access.

The database accesses and changes that occur in the update part of your application.

Code Inspector

The Code Inspector is a tool for checking Repository objects regarding performance, security, syntax, and adherence to name conventions.

also check the below document.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/695918cd-0d01-0010-2091-d7862084...

Regards,

Satish

[Former Member]

hi bramara,

ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are some tips to speed up your programs and reduce the load your programs put on the system:

Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.

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 expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful program design, and by using commands such as 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. This can 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 to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records). If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space.

Use as many table keys as possible in the WHERE part of your select statements.

Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.

Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.

Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.

Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_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 of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.

If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have 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). Use these avoid wasting resources by calculating a total that has already been calculated and stored.

reward if useful..

[SantoshKallem]

http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp

http://www.sapdevelopment.co.uk/perform/performhome.htm

http://www.dbis.ethz.ch/research/publications/19.pdf

regards.

santhosh reddy

Message was edited by:

Santhosh Reddy

[Former Member]

HI

points to improve performance in the report

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.

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

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

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

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

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.

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.

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

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

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.

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

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

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

APPEND LINES OF ITAB1 TO ITAB2.

This is more optimized as compared to

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

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

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.

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

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

ITAB2[] = ITAB1[].

This is much more optimized as compared to

REFRESH ITAB2.

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

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

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

[Former Member]

HI

Tools for Performance Analysis

Run time analysis transaction SE30

SQL Trace transaction ST05

Extended Program Check (SLIN)

Code Inspector ( SCI)

Run time analysis transaction SE30 :This transaction gives all the analysis of an ABAP program with respect to the database and the non-database processing. 

SQL Trace transaction ST05: The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.

The trace list contains different SQL statements simultaneously related to the one SELECT statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated component of the R/3 Application Server - maps every Open SQL statement to one or a series of physical database calls and brings it to execution. This mapping, crucial to R/3s performance, depends on the particular call and database system. For example, the SELECT-ENDSELECT loop on a particular database table of the ABAP program would be mapped to a sequence PREPARE-OPEN-FETCH of physical calls in an Oracle environment.

The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP statement. This is because in an R/3 system, a client is a self-contained unit with separate master records and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open SQL statement automatically executes within the correct client environment. For this reason, a condition with the actual client code is added to every WHERE clause if a client field is a component of the searched table.

To see a statement's execution plan, just position the cursor on the PREPARE statement and choose Explain SQL. A detailed explanation of the execution plan depends on the database system in use.

Extended Program Check

This can be called in through transaction SE38 or through transaction SLIN. This indicates possible problems that may cause performance problems.

Code Inspector (SCI)

You can call the Code Inspector from the ABAP Editor (SE38), the Function Builder (SE37), the Class Builder (SE24), or as a separate transaction (SCI).

The Code Inspector indicates possible problems. However, note that, especially with performance issues: There is no rule without exception. If a program passes an inspection, it does not necessarily mean that this program will have no performance problems.

[Former Member]

hi,

Following are the performance standards need to be following in writing ABAP programs:

1. Unused/Dead code

Avoid leaving unused code in the program. Either comment out or delete the unused situation. Use program --> check --> extended program to check for the variables, which are not used statically.

2. Subroutine Usage

For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:

This is better:

IF f1 NE 0.

PERFORM sub1.

ENDIF.

FORM sub1.

...

ENDFORM.

Than this:

PERFORM sub1.

FORM sub1.

IF f1 NE 0.

...

ENDIF.

ENDFORM.

3. Usage of IF statements

When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND , place the mostly likely false first and for the OR, place the mostly likely true first.

Example - nested IF's:

IF (least likely to be true).

IF (less likely to be true).

IF (most likely to be true).

ENDIF.

ENDIF.

ENDIF.

Example - IF...ELSEIF...ENDIF :

IF (most likely to be true).

ELSEIF (less likely to be true).

ELSEIF (least likely to be true).

ENDIF.

Example - AND:

IF (least likely to be true) AND

(most likely to be true).

ENDIF.

Example - OR:

IF (most likely to be true) OR

(least likely to be true).

4. CASE vs. nested Ifs

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.

5. MOVE statements

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.

MOVE BSEG TO *BSEG.

is better than

MOVE-CORRESPONDING BSEG TO *BSEG.

6. SELECT and SELECT SINGLE

When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to three times.

7. Small internal tables vs. complete internal tables

In general it is better to minimize the number of fields declared in an internal table. While it may be convenient to declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.

For example:

Instead of this:

data: t_mara like mara occurs 0 with header line.

Use this:

data: begin of t_mara occurs 0,

matnr like mara-matnr,

...

end of t_mara.

8. Row-level processing and SELECT SINGLE

Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple SELECT-SINGLE commands on a non-buffered table (check Data Dictionary -> Technical Info), you should do the following to improve performance:

Use the SELECT into <itab> to buffer the necessary rows in an internal table, then

sort the rows by the key fields, then

use a READ TABLE WITH KEY ... BINARY SEARCH in place of the SELECT SINGLE command. Note that this only make sense when the table you are buffering is not too large (this decision must be made on a case by case basis).

9. READing single records of internal tables

When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should:

SORT the table

use READ TABLE WITH KEY BINARY SEARCH for better performance.

10. SORTing internal tables

When SORTing internal tables, specify the fields to SORTed.

SORT ITAB BY FLD1 FLD2.

is more efficient than

SORT ITAB.

11. Number of entries in an internal table

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.

12. Performance diagnosis

To diagnose performance problems, it is recommended to use the SAP transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and programs.

13. Nested SELECTs versus table views

Since releASE 4.0, OPEN SQL allows both inner and outer table joins. A nested SELECT loop may be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should either create a view in the data dictionary then use this view to select data, or code the select using a join.

14. If nested SELECTs must be used

As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:

Use this:

form select_good.

data: t_vbak like vbak occurs 0 with header line.

data: t_vbap like vbap occurs 0 with header line.

select * from vbak into table t_vbak up to 200 rows.

select * from vbap

for all entries in t_vbak

where vbeln = t_vbak-vbeln.

...

endselect.

endform.

Instead of this:

form select_bad.

select * from vbak up to 200 rows.

select * from vbap where vbeln = vbak-vbeln.

...

endselect.

endselect.

endform.

Although using "SELECT...FOR ALL ENTRIES IN..." is generally very fast, you should be aware of the three pitfalls of using it:

Firstly, SAP automatically removes any duplicates from the rest of the retrieved records. Therefore, if you wish to ensure that no qualifying records are discarded, the field list of the inner SELECT must be designed to ensure the retrieved records will contain no duplicates (normally, this would mean including in the list of retrieved fields all of those fields that comprise that table's primary key).

Secondly, if you were able to code "SELECT ... FROM <database table> FOR ALL ENTRIES IN TABLE <itab>" and the internal table <itab> is empty, then all rows from <database table> will be retrieved.

Thirdly, if the internal table supplying the selection criteria (i.e. internal table <itab> in the example "...FOR ALL ENTRIES IN TABLE <itab> ") contains a large number of entries, performance degradation may occur.

15. SELECT * versus SELECTing individual fields

In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performace gains can be substantial. For example:

Use:

select vbeln auart vbtyp from table vbak

into (vbak-vbeln, vbak-auart, vbak-vbtyp)

where ...

Instead of using:

select * from vbak where ...

16. Avoid unnecessary statements

There are a few cases where one command is better than two. For example:

Use:

append <tab_wa> to <tab>.

Instead of:

<tab> = <tab_wa>.

append <tab> (modify <tab>).

And also, use:

if not <tab>[] is initial.

Instead of:

describe table <tab> lines <line_counter>.

if <line_counter> > 0.

17. Copying or appending internal tables

Use this:

<tab2>[] = <tab1>[]. (if <tab2> is empty)

Instead of this:

loop at <tab1>.

append <tab1> to <tab2>.

endloop.

However, if <tab2> is not empty and should not be overwritten, then use:

append lines of <tab1> [from index1] [to index2] to <tab2>.

[Former Member]

hi,

PLEASE REWARD IF PREVIOUS ANSWER GIVEN BY ME IS USEFUL FOR YOU.

[Former Member]

Dear Bramara,

<b>The following guidelines can be used to improve the performance of an ABAP Program:</b>

1. Follow the naming standards (of the company or client you are working)

2. Use select field one field two etc do not use select *

3. Avoid unnecessary loops. If requirec use loop with where clause or Read with binary search

4. Use case statement in place of if else

5. use clear table before select single or where ever applicable.

6. check for sy-subrc where ever applicable

7. avoid collect statement if possinble

8. do proper documentation of the program inside abap editor and also in se38 (screen-documentation radio button )

9. try to use views rather than nested select statement

10. use ABAP TRACE try to work on those SQL statements to improve performance

11. use index only if it is required

12. in internal table declaration try to use correct occurs number say occurs 1000. Otherwise use occurs 0.

13. while using select statements use single select, select * upto 5 rows ,etc based on the requirement.use select options wisely taking performance into account.

14. declare variables / parameters with meaningful words like v_matnr for material number or v_bukrs for plant or at least v_matnum for material number etc.

15. Beautify the code using pretty printer, pattens(***** ——- etc)

Regards,

Rajesh K Soman

<b>Kindly reward points if found helpful.</b>