performance tuning questions

[Former Member]

i am fresher in sap-abap. so i have some doubts.

how to increase performance in a report. what r the minimum steps to follow.

expecting the answer more clearly

[Former Member]

Hi,

Many guys have answered this question in this forum. Please search.

The 2 critical parts for the performance review of a program:

1. SELECT statements

2. Internal Table access

Regards,

Sumant.

[Former Member]

Hi,

There are many ways to increase the performance like using SELECTs and LOOPS more efficiently...etc..

U can go thru there links ..u can get some idea about how to increase ABAP performance.

http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm

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

[Former Member]

Hi Josh,

Here is a detailed document for performance check:

<b>AWARD POINTS IF IT HELPS:</b>

5.1 SQL

In order to enhance the performance of your ABAP code a number of useful guidelines can be used.

• Use SELECT SINGLE wherever possible to retrieve up to one row of information. It is important to specify all the key fields to ensure a unique record.

• Be careful using the FOR ALL ENTRIES addition since this is very bad for very large datasets (10,000+ records)

• Joins and subqueries are good

• Do not use SELECT * statement unless the program needs ALL columns from the table. Instead, only specify the fields you require. This will also avoid unnecessary network transports. The addition INTO CORRESPONDING FIELDS of the INTO clause of the SELECT statement is worthwhile to use only for large amounts of data where the external table and destination fields have the same names. Consider the use of the DISTINCT option in the case of many duplicate entries.

The following example compares selecting all fields to selecting only the document number, the item number and the material.

Avoid:. select * from vbap

where vbeln in s_docno.

….

endselect.

Use: select vbeln posnr matnr

into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)

from vbap

where vbeln in s_docno.

….

endselect.

Important Points:

The order of the fields retrieved must match the order of the destination fields in the field list.

• Use the SELECT...WHERE clause to restrict data rather than retrieve all rows and use a CHECK or IF statements to filter data.

Avoid: select vbeln posnr matnr

into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)

from vbap.

check s_docno.

….

endselect.

Use: select vbeln posnr matnr

into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)

from vbap

where vbeln in s_docno.

….

endselect.

Important Points:

Order the columns in the where clause of a select in the same order as the key or index table.

• WHERE Clause Tips

o Exploit the indexes of the database tables for an efficient use of the WHERE clause. To do so check all index fields with the equality operator (EQ, 😃 and concatenate these checks by AND. The primary key of a database table makes up its primary index automatically. Secondary indexes for a database table can be created in the ABAP Dictionary.

o If possible, include all columns of the key or an index in the where clause. Use a default or appropriate value. If the column(s) is not included, the database may not be able to fully utilise the index.

o Avoid complex WHERE clauses. The system must split up those into single statements for the database system.

o Do not use the logical NOT in WHERE clauses but inverted operators instead. The logical NOT is not supported by the database indexes.

• Try to avoid the select … endselect programming construct. Rather select all the required records from the database directly into an internal table and loop at the table to process the entries. This is usually faster than the select … endselect code, and also allows easier debugging of the code.

Avoid: select vbeln posnr matnr

into (wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr)

from vbap

where vbeln in s_docno.

write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr.

endselect.

Use: select vbeln posnr matnr into table ts_vbap

from vbap

where vbeln in s_docno.

loop at ts_vbap into wa_vbap.

write:/ wa_vbap-vbeln, wa_vbap-posnr, wa_vbap-matnr.

Endloop.

• Avoid nested select statements if possible as they generally have poor performance. It is preferable to select all the entries for each table directly into an internal table and use nested internal table loops to process all the entries.

• Check runtime analysis tips and tricks for detailed comparisons in select performance (SM30). SELECT statements.

• Use aggregate expressions in the SELECT clause to perform calculations instead of transporting great amounts of data and calculating thereafter. This distributes the processing load and minimises the network data transfer. Valid aggregate functions include: MAX, MIN, AVG, SUM and COUNT.

• The storage of database tables in local buffers can lead to significant time savings. Use the buffering of database tables whenever possible. Use the addition BYPASSING BUFFER only if it is really necessary.

If DISTINCT, SINGLE FOR UPDATE, and aggregate expressions are used in the SELECT clause, buffering should be turned off.

• Provide the appropriate selection criteria to limit the number of data base reads. Force users to provide selection criteria by evaluating the selection criteria entered on the selection screen during the AT SELECTION-SCREEN event.

• Create indices where needed to enhance query performance. This should be used in large table lookups to increase efficiency. For example, SELECT…WHERE FieldA = ‘001’. In this case FieldA is not a key field, therefore an index should be created to improve the efficiency of the select statement. Beware that there is always an additional processing system overhead for indices. Therefore, only create indices if a major performance benefit will be realised, especially if the program concerned is executed many times throughout the day and is business critical.

5.1.1 SQL Checklist

• Keep the selected dataset small

• Keep the transferred data small

• Keep the number of database accesses small

• Use database buffers

• Create views for table joins instead of using multiple selects.

• Select data only one time where possible (i.e., don’t have multiple selects against the same table - get the data one time and store it in an internal table).

• Remove unused indexes from tables.

5.2 General Programming Techniques

Detailed below are a number of additional programming techniques that should be borne in mind when implementing ABAP code.

• 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 the performance of the CASE is more efficient.

• Do not use MOVE CORRESPONDING unless the data is contiguous.

• 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, if records a and b have the exact same structure.

MOVE BSEG TO *BSEG. is better than

MOVE-CORRESPONDING BSEG TO *BSEG.

• Do not use the COLLECT statement with large internal tables as this can be very CPU intensive.

• When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ on a on a sorted table. Therefore, SORT the table and use READ TABLE WITH KEY BINARY SEARCH.

• Use the SORT...BY when sorting internal tables.

SORT ITAB BY FLD1 FLD2. is more efficient than

SORT ITAB.

• Avoid hard-coding and use of literals in ABAP code. Use reference tables to drive processing to support business change flexibility and reduce ongoing maintenance costs. If hard-coding and literals are required, be sure to include these as constants.

• The Tips & Tricks function is very useful in comparing different methods of coding without going to the trouble of coding both and then performing your own run-time analysis. System > Utilities > Runtime Analysis > Tips & Tricks.

5.3 Logical Databases

Use logical databases and ‘GET’ events wherever reads on parent/child segments need to be performed e.g. require data from both MARA then MARD table - use GET MARA then GET MARD. (Note you do not need to use an LDB if data from only the MARA or MARD table is required.)

Where an LDB is used provide defaults or checks for the standard selection-options/parameters wherever possible.

Avoid use of logical data bases as much as possible - use SELECT statements instead. (Logical databases are good as a reference tool to look up database hierarchies).

&#61558; Logical database should only be used when there are no other options.

&#61558; Use of Logical database in ABAP programs must be approved by a DEVELOPMENT TEAM LEAD

&#61558; Due to strategic importance of LDB’s and the potential impact on system performance, careful consideration should be made before creating new LDB’s. Consequently no LDB’s should be created without approval from the Development Team Lead

5.4 Debugging

When testing ABAP, use of the debugging tool plays an essential role in checking the value of variables during the execution of the program. This tool should be used during the unit testing to ensure programs are executing as desired.

You can use the debugging tool by selecting Program > Debugging from the ABAP program Development Initial screen.

In addition to the static programming of breakpoints, ABAP’s on-line debugging tools also allow you to set breakpoints and interrupt conditions dynamically. This makes the whole process of debugging reports much more flexible and the consequent advantage is that you do not have to change your code. Watchpoints can now be set based on the value a field takes (like R/2).

Once you have stopped the report processing, you can view the contents of all the fields (up to 8), internal tables and database tables referenced in the report. The system fields SY-TABIX and SY-DBCNT are now displayed at the bottom of the screen along with SY-SUBRC.

Finally, you can change the contents of fields for debugging purposes and then resume report processing, with the changed data. To set breakpoints select Breakpoints > Set from the ABAP: Editor screen. Then execute the program.

Beware that in order to debug SAPscript programs, hard-coded breakpoints are often required. Be sure to remove these once testing is complete and the program transported. Use the syntax BREAK username, rather than BREAK-POINT, as this will ensure the code only stops when running under the specified username.

6 SAPscript Techniques

6.1 Good Practice

• Always copy the SAP standard print programs where available and, in most instances, the layout set. Never start a complex SAPscript (e.g. Invoice, Purchase Order) from the beginning, as this will require far more development time to complete.

• When creating a new layout set by copying a SAP standard, always change the original language from D to E and then activate.

6.2 Standards

• Naming convention for layout sets – this will follow the same as the program name, except the version number will be prefixed L. For example a purchase order layout set would be:

ZMM_DESC where

Z First character of the program

MM SAP R/3 module/component

DESC Meaningful description i.e. PO printing, INVOICE.

• When copying SAP standard print programs ensure they have a standard header block as defined earlier. Also ensure that any code that is added, removed or changed is commented in the standard fashion.

6.3 Standard Texts

• These should be of the following format:

ZXX_DESC

Where:

Z First character of the program

XX Module name

DESC Meaningful description.

6.4 Tips

• Text elements must be maintained individually for each layout set language. Any other changes to the layout set i.e. window size or paragraphs, will be copied from the original language to the other languages.

&#61558; As layout sets are client-dependant they must be ‘transported’ between clients on the same box. To do this use the ‘Copy from Client’ function from within the ‘target’ client. This is language specific.

&#61558; Always ACTIVATE the layout set each change and in each language before transporting.

&#61558; The SAPscript debugger can be sent useful, this is turned on at the front screen on transaction SE71.

&#61558; Standard text used within a layout set must be assigned to a transport request using the program RSTXTRAN. Once assigned the transport request can be released in the usual manner via SE10.

7 Changing the SAP Standard

• You can adjust the R/3 System to meet your needs in the following ways:

o Customizing: This means setting up specific business processes and functions for your system according to an implementation guide. The need for these changes has already been foreseen by SAP and an implementation procedure has been developed.

o Personalization: This means making changes to certain fields' global display attributes (setting default values or fading fields out altogether), as well as creating user-specific menu sequences.

o Modifications: These are changes to SAP Repository objects made at the customer site. If SAP delivers a changed version of the object, the customer's system must be adjusted to reflect these changes. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

o Enhancements: This means creating Repository objects for individual customers that refer to objects that already exist in the SAP Repository.

o Customer Developments: This means creating Repository objects unique to individual customers in a specific namespace reserved for new customer objects.

• If your requirements cannot be met by Customizing or personalization, you may either start a development project or try using a CSP solution (= Complementary Software Product).

• A development project falls into the customer development category if the SAP standard does not already contain functions similar to the one you are trying to develop. If, however, a similar SAP function exists, try to assimilate it into your development project by either enhancing or modifying it, by using a user exit, or simply by making a copy the appropriate SAP program.

• Modifications can create problems, as new versions of SAP objects must be adjusted after an upgrade to coincide with modified versions of SAP objects you have created. Prior to Release 4.0B these adjustments had to be made manually using upgrade utilities. From Release 4.5A, this procedure has been automated with the Modification Assistant.

• Thus, you should only make modifications if:

• Customizing or personalizing cannot satisfy your requirements

• Enhancements or user exits are not planned

• It would not make sense to copy the SAP object to the customer namespace.

7.1 Originals and copies

• An object is original in only one system. In the case of objects delivered by SAP, the original system is at SAP itself. These objects are only copies in customer systems. This applies to your development system and all other systems that come after it.

• If you write your own applications, the objects that you create are original in your development system. You assign your developments to a change request, which has the type Development/Correction.

This request ensures that the objects are transported from the development system into the subsequent systems

7.2 Corrections and repairs

• Changes to an original are called corrections. They are recorded in a change request whose tasks have the type "Development/correction".

• If, on the other hand, you change a copy (an object outside its own original system), the change is recorded in a task with the type "Repair". Repairs to SAP objects are called modifications.

• When you repair your own objects (for example, if something goes wrong in your production system), you can correct the original in your development system straight away. When you change copies, you must correct the original immediately!

• However, you cannot do this with SAP objects, because they are not original in any of your systems.

• You should only modify the SAP standard if the modifications you want to make are absolutely necessary for optimizing workflow in your company. Be aware that good background knowledge of application structure and flow are important prerequisites for deciding what kind of modifications to make and how these modifications should be designed.

7.3 Modifications and upgrades

During an upgrade or an import of R/3 Support Packages, new objects delivered overwrite existing objects of the SAP standard. In order to help customers keep those objects that have been modified in a previous release, SAP now offers upgrade adjustment for all objects being upgraded in the form of transactions SPAU and SPDD. These transactions allow customers to enter their modifications into the corresponding new objects being delivered at upgrade. The Modification Assistant supports this process of adopting customer modifications. In general, objects altered using the Modification Assistant can now be automatically accepted into the upgraded system if the modifications undertaken in the original version do not directly overlap those made in the customer version. If collisions occur between the two versions at upgrade (naming collisions, or if SAP has deleted an object modified by a customer), the system offers semi-automatic adjustment support. In some cases, however, you may still have to manually adjust objects using ABAP Workbench tools.

• Whenever you upgrade your system, apply a support package, or import a transport request, conflicts can occur with modified objects.

• Conflicts occur when you have changed an SAP object and SAP has also delivered a new version of it. The new object delivered by SAP becomes an active object in the Repository of your system.

• If you want to save your changes, you must perform a modification adjustment for the objects. If you have a lot of modified SAP objects, your upgrade can be slowed down considerably.

• To ensure consistency between your development system and subsequent systems, you should only perform modification adjustments in your development system. The objects from the adjustment can then be transported into other systems.

7.4 Modifications Procedures

• A registered developer must register changes to SAP objects. Exceptions to this registration are matchcodes, database indexes, buffer settings, customer objects, patches, and objects whose changes are based on automatic generation (for example, in Customizing). If the object is changed again at a later time, no new query is made for the registration key. Once an object is registered, the related key is stored locally and automatically copied for later changes, regardless of which registered developer is making the change. For the time being, these keys remain valid even after a release upgrade.

• How do you benefit from SSCR (SAP Software Change Registration)?

o Quick error resolution and high availability of modified systems

All objects that have been changed are logged by SAP. Based on this information, SAP's First Level Customer Service can quickly locate and fix problems. This increases the availability of your R/3 system.

o Dependable operation

Having to register your modifications helps prevent unintended modification. This in turn ensures that your R/3 software runs more reliably.

o Simplification of upgrades

Upgrades and release upgrades become considerably easier due to the smaller number of modifications.

7.5 Modifications Assistant

The aim of the Modification Assistant is to make modification adjustments easier. This is because (among other reasons) the modifications are registered in a different layer

• If you want to change an SAP object, you must provide the following information:

o SSCR key

o Change request

• The system informs you that the object is under the control of the Modification Assistant. Only restricted functions are available in the editor.

• You can switch the Modification Assistant on or off for the entire system by changing the R/3 profile parameter eu/controlled_modification. SAP recommends that you always work with the Modification Assistant.

• You can switch off the Modification Assistant for single Repository Objects. Once you have done so, the system no longer uses the fine granularity of the Modification Assistant.

• In modification mode, you have access to a subset of the normal editor tools. You can access these using the appropriate pushbuttons. For example, in the ABAP Editor, you can:

o Insert

The system generates a framework of comment lines between which you can enter your source code.

o Replace

Position the cursor on a line and choose Replace. The corresponding line is commented out, and another line appears in which you can enter coding. If you want to replace several lines, mark them as a block first.

o Delete

Select a line or a block and choose Delete. The lines are commented out.

o Undo modifications

This undoes all of the modifications you have made to this object.

o Display modification overview

Choose this function to display an overview of all modifications belonging to this object.

7.6 Restoring the original

You can reset all of the modifications that you have made to the current object using the Modification Assistant by choosing this function. The record of the modifications is also deleted.

Remember that you cannot selectively undo modifications to an object. You can only undo modifications based on the "all or nothing" principle.

&#61558; Any modifications in standard SAP object will require proper justification and needs to be documented. The rights of modification the standard SAP object is limited to PROJECT MANGER only.

Cheers,

ashish.

[Former Member]

Hey josh,

Please following the above solutions and close the thread.

Regards,

Kumar.

[Former Member]

Hi josh,

Go through this info.

You can see a report performance in SE30(Runtime analysis)and

SQLtrace(ST05).

ST05 tells you the list of selected statements.

You should remember some points when you tuning the code

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

Try to avoid joins more than 2 tables.

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)

Some steps that might make FOR ALL ENTRIES more efficient:

Removing duplicates from the the driver table

Sorting the driver table

If possible, convert the data in the driver table to ranges so a BETWEEN statement is used instead of and OR statement:

FOR ALL ENTRIES IN i_tab

WHERE mykey >= i_tab-low and

mykey <= i_tab-high.

Nested selects

The plus:

Small amount of data

Mixing processing and reading of data

Easy to code - and understand

The minus:

Large amount of data

when mixed processing isn’t needed

Performance killer no. 1

Select using JOINS

The plus

Very large amount of data

Similar to Nested selects - when the accesses are planned by the programmer

In some cases the fastest

Not so memory critical

The minus

Very difficult to program/understand

Mixing processing and reading of data not possible

Use the selection criteria

SELECT * FROM SBOOK.

CHECK: SBOOK-CARRID = 'LH' AND

SBOOK-CONNID = '0400'.

ENDSELECT.

SELECT * FROM SBOOK

WHERE CARRID = 'LH' AND

CONNID = '0400'.

ENDSELECT.

Use the aggregated functions

C4A = '000'.

SELECT * FROM T100

WHERE SPRSL = 'D' AND

ARBGB = '00'.

CHECK: T100-MSGNR > C4A.

C4A = T100-MSGNR.

ENDSELECT.

SELECT MAX( MSGNR ) FROM T100 INTO C4A

WHERE SPRSL = 'D' AND

ARBGB = '00'.

Select with view

SELECT * FROM DD01L

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

SELECT SINGLE * FROM DD01T

WHERE DOMNAME = DD01L-DOMNAME

AND AS4LOCAL = 'A'

AND AS4VERS = DD01L-AS4VERS

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

SELECT * FROM DD01V

WHERE DOMNAME LIKE 'CHAR%'

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

Select with index support

SELECT * FROM T100

WHERE ARBGB = '00'

AND MSGNR = '999'.

ENDSELECT.

SELECT * FROM T002.

SELECT * FROM T100

WHERE SPRSL = T002-SPRAS

AND ARBGB = '00'

AND MSGNR = '999'.

ENDSELECT.

ENDSELECT.

Select … Into table

REFRESH X006.

SELECT * FROM T006 INTO X006.

APPEND X006.

ENDSELECT

SELECT * FROM T006 INTO TABLE X006.

Select with selection list

SELECT * FROM DD01L

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

ENDSELECT

SELECT DOMNAME FROM DD01L

INTO DD01L-DOMNAME

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

ENDSELECT

Key access to multiple lines

LOOP AT TAB.

CHECK TAB-K = KVAL.

" ...

ENDLOOP.

LOOP AT TAB WHERE K = KVAL.

" ...

ENDLOOP.

Copying internal tables

REFRESH TAB_DEST.

LOOP AT TAB_SRC INTO TAB_DEST.

APPEND TAB_DEST.

ENDLOOP.

TAB_DEST[] = TAB_SRC[].

Modifying a set of lines

LOOP AT TAB.

IF TAB-FLAG IS INITIAL.

TAB-FLAG = 'X'.

ENDIF.

MODIFY TAB.

ENDLOOP.

TAB-FLAG = 'X'.

MODIFY TAB TRANSPORTING FLAG

WHERE FLAG IS INITIAL.

Deleting a sequence of lines

DO 101 TIMES.

DELETE TAB_DEST INDEX 450.

ENDDO.

DELETE TAB_DEST FROM 450 TO 550.

Linear search vs. binary

READ TABLE TAB WITH KEY K = 'X'.

READ TABLE TAB WITH KEY K = 'X' BINARY SEARCH.

Comparison of internal tables

DESCRIBE TABLE: TAB1 LINES L1,

TAB2 LINES L2.

IF L1 <> L2.

TAB_DIFFERENT = 'X'.

ELSE.

TAB_DIFFERENT = SPACE.

LOOP AT TAB1.

READ TABLE TAB2 INDEX SY-TABIX.

IF TAB1 <> TAB2.

TAB_DIFFERENT = 'X'. EXIT.

ENDIF.

ENDLOOP.

ENDIF.

IF TAB_DIFFERENT = SPACE.

" ...

ENDIF.

IF TAB1[] = TAB2[].

" ...

ENDIF.

Modify selected components

LOOP AT TAB.

TAB-DATE = SY-DATUM.

MODIFY TAB.

ENDLOOP.

WA-DATE = SY-DATUM.

LOOP AT TAB.

MODIFY TAB FROM WA TRANSPORTING DATE.

ENDLOOP.

Appending two internal tables

LOOP AT TAB_SRC.

APPEND TAB_SRC TO TAB_DEST.

ENDLOOP

APPEND LINES OF TAB_SRC TO TAB_DEST.

Deleting a set of lines

LOOP AT TAB_DEST WHERE K = KVAL.

DELETE TAB_DEST.

ENDLOOP

DELETE TAB_DEST WHERE K = KVAL.

Tools available in SAP to pin-point a performance problem

The runtime analysis (SE30)

SQL Trace (ST05)

Tips and Tricks tool

The performance database

Optimizing the load of the database

Using table buffering

Using buffered tables improves the performance considerably. Note that in some cases a stament can not be used with a buffered table, so when using these staments the buffer will be bypassed. These staments are:

Select DISTINCT

ORDER BY / GROUP BY / HAVING clause

Any WHERE clasuse that contains a subquery or IS NULL expression

JOIN s

A SELECT... FOR UPDATE

If you wnat to explicitly bypass the bufer, use the BYPASS BUFFER addition to the SELECT clause.

Use the ABAP SORT Clause Instead of ORDER BY

The ORDER BY clause is executed on the database server while the ABAP SORT statement is executed on the application server. The datbase server will usually be the bottleneck, so sometimes it is better to move thje sort from the datsbase server to the application server.

If you are not sorting by the primary key ( E.g. using the ORDER BY PRIMARY key statement) but are sorting by another key, it could be better to use the ABAP SORT stament to sort the data in an internal table. Note however that for very large result sets it might not be a feasible solution and you would want to let the datbase server sort it.

Avoid ther SELECT DISTINCT Statement

As with the ORDER BY clause it could be better to avoid using SELECT DISTINCT, if some of the fields are not part of an index. Instead use ABAP SORT + DELETE ADJACENT DUPLICATES on an internal table, to delete duplciate rows.

Rewords points.

Rgds,

P.Nag

[Former Member]

Hi,

ABAP report performance is divided into three catagoreis :

1. Database

2. System

3. ABAP

Out of which database load should be at least and can be shared by mostly ABAP section only. Means you have to take care that there should be least possible load ob DB.

This can be achieved using proper and PERFECT sql statements.

ABAP part can be improved using REad table BINARY SEARCH, loop, wa, etc.

Go to Se30: Performannce analyser. and click on Tips and tricks you will get very helpful hints than any other place.

Hope this iwll help you.

Award if helps.

Jogdand M B

[Former Member]

Hi Josh,

The basic problem with the performance tuning is select statements. Find some of them below which i've gathered some long time ago.

1. Always check the driver internal tables are not empty, while using FOR ALL

ENTRIES.

2. Avoid for all entries in JOINS

3. Try to avoid joins and use FOR ALL ENTRIES.

4. Try to restrict the joins to 1 level only i.e. only for 2 tables

5. Avoid using Select *.

6. Avoid having multiple Selects from the same table in the same object.

7. Try to minimize the number of variables to save memory.

8. The sequence of fields in 'where clause' must be as per primary/secondary index (if

any).

9. Avoid creation of index as far as possible

10. Avoid operators like <>, >, < & like % in where clause conditions

11. Avoid select/select single statements in loops.

12. Try to use 'binary search' in READ internal table. Ensure table is sorted before

using BINARY SEARCH.

13. Avoid using aggregate functions (SUM, MAX etc) in selects (GROUP BY, HAVING,)

14. Avoid using ORDER BY in selects

15. Avoid Nested Selects

16. Avoid Nested Loops of Internal Tables

17. Try to use FIELD SYMBOLS.

18. Try to avoid into Corresponding Fields of

19. Avoid using Select Distinct, Use DELETE ADJACENT.

<b>NOTE: AWARD POINTS FOR USEFUL ANSWERS</b>

Regards,

Sekhar.

[alison_lloyd]

go to se30 -> tips and tricks to see many of the points mentioned above

Run st05 to see if particular select statements are giving a problem - sumarise by table to see a useful view

Run se30 to see if code or database is the issue.

[Former Member]

Hi Josh,

follow the steps mentioned for better performance:

1) Don’t use nested select statement

2) If possible use for all entries in addition

3) In the where addition make sure you give all the primary key

4) Use Index for the selection criteria.

5) You can also use inner joins

6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.

7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly

Check these links

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1...

/people/hema.rao/blog/2006/09/25/performance-tuning--an-overlooked-activity

/people/rob.burbank/blog/2007/03/19/joins-vs-for-all-entries--which-performs-better

/people/rob.burbank/blog/2006/02/07/performance-of-nested-loops

http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm

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

Hope this resolves your query.

Reward all the helpful answers.

Regards

[Former Member]

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:

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

o sort the rows by the key fields, then

o 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:

o SORT the table

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

P.S : Please reward if you find this useful..

Regards,

Sandeep

[Former Member]

Hi,

Check the following.

1) select's

2) nested loops

3) sorting

Thanks

Sunil

[Former Member]

Hi,

Performance of ABAPs can be improved by minimizing the amount of data to be transferred.

The data set must be transferred through the network to the applications, so reducing the amount OF time and also reduces the network traffic.

Some measures that can be taken are:

- Use views defined in the ABAP/4 DDIC (also has the advantage of better reusability).

- Use field list (SELECT clause) rather than SELECT *.

- Range tables should be avoided (IN operator)

- Avoid nested SELECTS.

Reward points if it is helpful

Regards,

Sangeetha.A

[Former Member]

Hi ,

We can also use "buffering technique" to acess data faster.

Lets consider we have ztables that have tendencies to collect huge data and these tables are accessed by many applications , in this case we can buffer the ztable, this is done in data dictionary under technical settings.

Note : buffering is useful only when table has master data and that data doesn't change frequently.

Regards,

Garrick.