03-25-2008 6:14 AM
what are the reasons(Concepts) to deside program performance is not good?
03-25-2008 6:19 AM
goto se38
menu - environment
click on - performance examples
you will get all the examples.. click to view
03-25-2008 6:20 AM
One of the main criteria is no of records processed or retrieved per unit time. Also the program should be scalable - means if you add more processing power the performance should be better.
Another guiding factor is how you are going to run the program, a month end batch job is definitely going to take more time and you are not going rin it online. So the batch job should finish within the stipulated time (say 3 hours).
SE30 is a good way to tell yoi where the program is taking more time. ST05 will give you detailed data retrieval analysis.
03-25-2008 6:24 AM
hi,
Follow this for the standard performance guidlines
Run Extended syntax checks with character literals checkbox switched on & Code Inspector to rectify all relevant errors and warning (e.g. Use the results of the above checks to remove all variables/constants etc that are declared but are not used)
Transaction SE30 (ABAP Runtime Analysis) must be checked to measure/compare program performance/runtime if program has multiple inefficient databases selects or complicated internal table operations
Use transaction ST05 (SQL Trace) to see what indices your database accesses are using. Check these indices against your where clause to assure they are significant. Check other indices for this table and where you have to change your where clause to use it. Create new indices if necessary, but do not forget to check the impact by consulting onsite coordinator.
TYPE (data element) command is used while declaring the fields whenever feasible instead of LIKE. Remember not always the data element name matches with the table field name
Internal Table is defined with TYPE STANDARD TABLE OF & Work-Areas is used instead of header lines
Global variables are minimized by declaring local variables or by passing variables through parameters & arguments while creating internal subroutine(s)
In SELECT statement, only the required fields are selected in the same order as they reside on the database table/structure/view
For selecting single row from a database table, SELECT UP to 1 Rows is used. Select Single is used only when full primary key combination is known
No SELECT * is used
Use SELECT INTO TABLE rather than SELECT INTO CORRESPONDING FIELDS OF TABLE
Always specify as many primary keys as possible in WHERE clause to make the Select efficient
Always select into an internal table, except when the table will be very large (i.e., when the internal table will be greater than 500,000 records). Use Up to N Rows when the number of records needed is known
Select statement within a GET event is not used
Wild cards like A% is avoided as much as possible
Nested Select is not used instead Inner Join and/or For all Entries is used. For all Entries is to be used over Loop at ITAB / Select / ENDLOOP (FOR ALL ENTRIES retrieves a unique result set so ensure you retrieve the full key from the database)
When creating joins over database tables there should be an index at least on the inner table for the fields in the join condition else use FOR ALL ENTRIES select statement
Usage of JOIN is limited to a maximum of 2 i.e. not more than 3 database tables are joined at one time
CHECK that the internal table used in FOR ALL ENTRIES is NOT empty as this will retrieve all entries from the table
Delete adjacent duplicate entries from internal table before selection from database table using FOR ALL ENTRIES statement
For copying internal tables use = operator instead of Looping & Appending
SORT inside a LOOP is not used
Sort internal table by fields in the correct order, which are used in a READ TABLE statement using BINARY SEARCH. If the order of sorting is invalid the BINARY SEARCH will never work
For large internal tables where only some rows are to be processed, use SORT and then the READ TABLE command is used to set index to first relevant row before looping from that index. Use CHECK or IF EXIT ENDIF as appropriate to exit from the loop
Sort fields and Sort Order on the SORT statement should be mentioned explicitly (e.g. SORT ITAB BY FLD1 FLD2 ASCENDING)
Hashed table is used for processing large amount of data (provided that you access single records only, and all with a fully specified key)
DELETE or SORT is not used on a hashed table since it increases memory consumption
Sorted table is used for range accesses involving table key or index accesses
Fields specified in the WHERE condition with the critical operators NOT and <> (negative SQL statements) cannot be used for a search using database indexes. Whenever possible formulate SQL statements positively
When coding IF or CASE, testing conditions are nested so that the most frequently true conditions are processed first. Also CASE is used instead of IF when testing multiple fields equal to something
LOOP AT ITAB INTO WORKAREA WHERE K = XXX should be used instead of LOOP AT ITAB INTO WORKAREA / CHECK ITAB-K = XXX.
Also READ TABLE INTO WORKAREA should be used instead of only READ TABLE.
After the APPEND statement inside a loop, the work area that has been appended is cleared
Internal tables, Work areas & Global Variables are freed when no longer needed (e.g. using the FREE / REFRESH command), especially when the tables are large or the program is a batch program
Do not delete the records of internal table inside the Loop End loop.
Do not use: LOOP AT ITAB WHERE EQUNR = 00001011.
DELETE ITAB.
ENDLOOP.
Use: DELETE ITAB WHERE EQUNR = 00001011.
Use the MODIFY ITAB ... TRANSPORTING f1 f2 ... for single line, and MODIFY ITAB ... TRANSPORTING f1 f2 ... WHERE condition for a set of line, to accelerate the updating of internal table
If possible, Update/Insert statement is used instead of Modify
Is the following steps ensured during database updates?
Lock data to be edited
Read current data from the database
Process data and write it to the database
Release the locks set at the beginning
Try to avoid logical databases. If your program uses a logical database, but does not require all fields belonging to a certain GET event, always use the FIELDS addition to reduce the amount of data selected by the logical database
Avoid the aggregate (Count, Max, Min) functions in the database selection
Use Parallel Cursor methods for nested loop into the internal tables if second internal table contains considerable number of records
In Smartform/ Sapscript do not make redundant data retrieval where data is available in interface
Hope this helps, Do reward.
03-25-2008 9:03 AM
Check
Code Inspector on your coding (tcode SCI)
Run traces SE30 and ST05 to get an iompression of the performance.
SQL trace:
/people/siegfried.boes/blog/2007/09/05/the-sql-trace-st05-150-quick-and-easy
SE30
/people/siegfried.boes/blog/2007/11/13/the-abap-runtime-trace-se30--quick-and-easy
Results will tell you whether there is room for improvement or not.
Siegfried
03-25-2008 8:10 PM
Hi srinivasarao,
Goto se30 and check there.
In that all the lines that appear in the graph should be green ,then ur program is having good performance,also goto report and Program->check->code inspector and extended program check. check those which will tel u the faults in ur program effecting the performance.
Thanks,
AMK.
Reward points if useful.
03-31-2008 10:18 AM
Hi,
1) Dont use nested select statements
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
ABAP performance depends upon various factors and in devicded in three parts:
1. Database
2. ABAP
3. System
Run Any program using SE30 (performance analys) to improve performance refer to tips and trics section of SE30, Always remember that ABAP perfirmance is improved when there is least load on Database.
u can get an interactive grap in SE30 regarding this with a file.
also if u find runtime of parts of codes then use :
Switch on RTA Dynamically within ABAP Code
*To turn runtim analysis on within ABAP code insert the following code
SET RUN TIME ANALYZER ON.
*To turn runtim analysis off within ABAP code insert the following code
SET RUN TIME ANALYZER OFF.
Always check the driver internal tables is not empty, while using FOR ALL ENTRIES
Avoid for all entries in JOINS
Try to avoid joins and use FOR ALL ENTRIES.
Try to restrict the joins to 1 level only ie only for tables
Avoid using Select *.
Avoid having multiple Selects from the same table in the same object.
Try to minimize the number of variables to save memory.
The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)
Avoid creation of index as far as possible
Avoid operators like <>, > , < & like % in where clause conditions
Avoid select/select single statements in loops.
Try to use 'binary search' in READ internal table. Ensure table is sorted before using BINARY SEARCH.
Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)
Avoid using ORDER BY in selects
Avoid Nested Selects
Avoid Nested Loops of Internal Tables
Try to use FIELD SYMBOLS.
Try to avoid into Corresponding Fields of
Avoid using Select Distinct, Use DELETE ADJACENT
Check the following Links
http://www.sapgenie.com/abap/performance.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
check the below link
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
See the following link if it's any help:
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Check also http://service.sap.com/performance
and
books like
http://www.sap-press.com/product.cfm?account=&product=H951
http://www.sap-press.com/product.cfm?account=&product=H973
http://www.sap-img.com/abap/more-than-100-abap-interview-faqs.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Performance tuning for Data Selection Statement
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
Debugger
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617ca9e68c11d2b2ab080009b43351/content.htm
http://www.cba.nau.edu/haney-j/CIS497/Assignments/Debugging.doc
http://help.sap.com/saphelp_erp2005/helpdata/en/b3/d322540c3beb4ba53795784eebb680/frameset.htm
Run Time Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617cafe68c11d2b2ab080009b43351/content.htm
SQL trace
http://help.sap.com/saphelp_47x200/helpdata/en/d1/801f7c454211d189710000e8322d00/content.htm
CATT - Computer Aided Testing Too
http://help.sap.com/saphelp_47x200/helpdata/en/b3/410b37233f7c6fe10000009b38f936/frameset.htm
Test Workbench
http://help.sap.com/saphelp_47x200/helpdata/en/a8/157235d0fa8742e10000009b38f889/frameset.htm
Coverage Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c7/af9a79061a11d4b3d4080009b43351/content.htm
Runtime Monitor
http://help.sap.com/saphelp_47x200/helpdata/en/b5/fa121cc15911d5993d00508b6b8b11/content.htm
Memory Inspector
http://help.sap.com/saphelp_47x200/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/content.htm
ECATT - Extended Computer Aided testing tool.
http://help.sap.com/saphelp_47x200/helpdata/en/20/e81c3b84e65e7be10000000a11402f/frameset.htm
Just refer to these links...
You can go to the transaction SE30 to have the runtime analysis of your program.Also try the transaction SCI , which is SAP Code Inspector.
1 Always check the driver internal tables is 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 ie 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.
Thanks®ards,
Sravani.