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?
- 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.
- Avoid nested loops when working with large internal tables.
- Use assign instead of into in LOOPs for large internal tables
- 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....
- 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*.*