0% found this document useful (0 votes)
81 views2 pages

Performance Tuning

There are several tools that can help with ABAP performance tuning. ST05 transaction allows measuring select statement performance while SE30 transaction measures overall application performance and provides tips. Code Inspector is a good static analysis tool that finds common mistakes and bottlenecks. Some tips for optimizing ABAP code include avoiding unnecessary SELECT statements, using indexes, enabling buffering, and reducing nested loops and SELECTs within loops. SELECT SINGLE returns the first match while SELECT...UP TO 1 ROWS retrieves and orders all matches, so SELECT SINGLE has better performance for checking existence. JOINS have overhead when the number of records is large, so FOR ALL ENTRIES may perform better in that case. Using "CHECK" and "CASE

Uploaded by

Sagar Naidu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
81 views2 pages

Performance Tuning

There are several tools that can help with ABAP performance tuning. ST05 transaction allows measuring select statement performance while SE30 transaction measures overall application performance and provides tips. Code Inspector is a good static analysis tool that finds common mistakes and bottlenecks. Some tips for optimizing ABAP code include avoiding unnecessary SELECT statements, using indexes, enabling buffering, and reducing nested loops and SELECTs within loops. SELECT SINGLE returns the first match while SELECT...UP TO 1 ROWS retrieves and orders all matches, so SELECT SINGLE has better performance for checking existence. JOINS have overhead when the number of records is large, so FOR ALL ENTRIES may perform better in that case. Using "CHECK" and "CASE

Uploaded by

Sagar Naidu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

What tools can be used to help with performance tuning?

ST05 is the SQL Trace transaction and can be used to measure the performance of the select statements of the program. SE30 is the Runtime Analysis transaction and can be used to measure the application performance. It also gives some tips on how to improve the performance through efficient code. One of the best tools for static performance analyzing is Code Inspector (SCI). There are many options for finding common mistakes and possible performance bottlenecks. What are the steps to optimise the ABAP Code? 1. 2. 3. 4. 5. 6. 7. 8. 9. Avoid using SELECT...ENDSELECT... construct and use SELECT ... INTO TABLE. Use WHERE clause in your SELECT statement to restrict the volume of data retrieved. Use as much index fields as possible from left to right in your WHERE statement Either enable buffering in your database table or create Indexes to speed up the query. 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. Whenever using READ TABLE use BINARY SEARCH addition to speed up the search. Be sure to sort the internal table before binary search. 10. Avoid nested loops when working with large internal tables. 11. Use assign instead of into in LOOPs for large internal tables 12. When in doubt call transaction SE30 and use the examples and check your code What is the difference between SELECT SINGLE and SELECT ... UP TO 1 ROWS? SELECT SINGLE returns the first matching row for the given condition and it may not be unique, if there are more matching rows for the given condition. SELECT ... UP TO 1 ROWS retrieves all the matching records and applies aggregation and ordering and returns the first record. Inorder to check for the existence of a record then it is better to use SELECT SINGLE than using SELECT ... UP TO 1 ROWS since it uses low memory and has better performance. Which is the better - JOINS or SELECT... FOR ALL ENTRIES...? When using FOR ALL ENTRIES the number of matching records is restricted to the number of records in the internal table. If the number of records in the database tables is too large then join would cause overheads in performance. Some things to consider....

1. Use "CHECK" instead of IF/ENDIF whenever possible. 2. Use "CASE" instead of IF/ENDIF whenever possible. 3. Use "MOVE" with individual variable/field moves instead of "MOVE-CORRESPONDING", creates
more coding but is more effcient*.*

You might also like