TCode for abap program performance testing

Question

Hi
I have tuned a abap program which was consuming lot of time. I still have the old version with diff name. I would like to know the tcodes where in i could see the performance of the program.
regards
Balaji

Answer 1

Hi balaji,
This is kiran Kumar.G.I will give some steps.you better to follow those steps to get ur report performance.
If u r satisfy with my answer give me REWARD POINTS.
            HAVE A NICE DAY.
STEPS:
1.OPEN UR REPORT IN SE38 TRANSACTION.
2.SELECT THE MENU PATH
  UTILITIES-->MORE UTILITIES-->RUNTIME ANALYSIS
3.SELECT THE PROGRAM RADIO BUTTON AND GIVE UR REPORT NAME THERE.AND CLICK <b>EXECUTE</b> BUTTON
4.IT WILL TAKE U TO ANOTHER SCREEN THERE U CAN EXECUTE UR REPORT AND COME BACK.
5.CLICK ON ANALYZE BUTTON.(PRESENT IN BELOW OF THE SCREEN).
THEN U WILL GET ONE GRAPH
NOTE:
1.IF IT IS RED UR PROGRAM IS HAVING VERY POOR PERFORMANCE
2.IF IT IS GREEN IT IS OK.
ABAP GRAPH : TELLS UR CODING IN THE REPORT.
DATABASE  GRAPH : U R RETREIVE DATA FROM DATABASE IN UR REPORT..
SOME STEPS USED TO IMPROVE UR PERFORMANCE:
1.     Avoid using SELECT...ENDSELECT... construct and use SELECT ... INTO TABLE.
2.     Use WHERE clause in your SELECT statement to restrict the volume of data retrieved.
3.     Design your Query to Use as much index fields as possible from left to right in your WHERE statement
4.     Use FOR ALL ENTRIES in your SELECT statement to retrieve the matching records at one shot.
5.     Avoid using nested SELECT statement, SELECT within LOOPs.
6.     Avoid using INTO CORRESPONDING FIELDS OF TABLE. Instead use INTO TABLE.
7.     Avoid using SELECT * and Select only the required fields from the table.
8.     Avoid nested loops when working with large internal tables.
9.     Use assign instead of into in LOOPs for table types with large work areas
10.     When in doubt call transaction SE30 and use the examples and check your code
11.     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.
12.     Use "CHECK" instead of IF/ENDIF whenever possible.
13.     Use "CASE" instead of IF/ENDIF whenever possible.
14.     Use "MOVE" with individual variable/field moves instead of "MOVE-
CORRESPONDING", creates more coding but is more effcient.
Regards,
Kiran Kumar.G