08-13-2007 10:46 AM
Hello friends,
I have made a zreport.
When i m running it, it is taking too much time.
What i do in the coding so that the execution time will decreace.
Please suggest me some idea....
Thanks in Advance
Dharmishta
08-13-2007 11:26 AM
Write better code !!!
Try to run SE30/ABAP trace. Get total time, get hitlist.
Try to improve the top 10 in the hit list.
Siegfried
08-13-2007 11:29 AM
Hi
please post u r code for studying or simply follw this steps....
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 isnt 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.
reward points to all helpful answers
kiran.M
08-13-2007 11:52 AM
HI
I THINK IN UR PROGRAMING UR USEING MANY LOOPS
OK DO ONE THING
GOTO SE38 -> OPEN UR PROGRAM -> MENU BAR PROGRAM-> CHECK -> CODE INSPECTOR / EXTENDED PROGRAMING CHECK
EXECUTE THIS
IT WILL SHOW ALL THE PERFORMANCE RELATED ERRORS THERE
IT WILL SHOW ALL THE ERORS AND WARNING S
IF TRY TO MAKE THESE POINTS AS ZERO THEN UR PROGRAM WILL EXECUTE FINE
RERD IF USEFULL
08-13-2007 12:04 PM
hi,
fallow my tips these are related to performance maximum of the time performance of the program will depends on the declaration of the <b>internal tables and writing select statements.</b>
for this use the fallowing tips :
<b>Internal Tables</b>
Internal tables are considered to be the true work horse of ABAP. They can have a big impact on processing and performance when programmed incorrectly. Use the quick checklist below to help guide you when coding internal table(itab) processing.
Internal Table Quick Checklist
Loop at itab must always use a work area or assign to a field symbol
Use parallel cursor technique for nested loops.
Use the TRANSPORTING clause with READ and MODIFY wherever possible to tranport only the fields necessary
Use TRANSPORTING No FIELDS clause when checking only for existence of a record
Read by INDEX is the fastest access option for a single READ. Use standard table if you are accessing mainly by index. Consider this where possible but use caution as it does not apply to all programming situations.
Specify full key on a table read whenever possible. Use WITH TABLE KEY clause when full key is specified
Internal Tables should be passed to FORMS with the "USING" clause. The "TABLES" clause is considered obsolete.
Internal tables should be passed to FORMS by Reference for performance reasons
i.e. do not use USING Value(..)
Do not use Occurs 0 or With Header Line unless it is a SAP function that requires it.
Hashed tables are a good performance approach over standard tables whenever random record accesses are required for a large internal table using the fully qualified key.
When sorting internal tables, always use "SORT BY Key1...n", never just "SORT" on it's own
Standard Tables require a Sort by, Delete adjacent Duplicates, and READ itab with KEY...Binary Search
Keep "SORT itab BY" statement as close as possible to the READ itab with KEY...Binary Search.
Delete Adjacent Duplicates should always be explicit by using the COMPARING clause, even if there is only one field in the itab
Standard Tables should be sorted by sorting keys to take advantage of Binary Search. However, if you sort by one key and Read with a different set, you could miss data
SELECT STATMENTS
As a programmer it is your job to always PROTECT the database. Avoid extensive DB I/O's and use memory over DB I/O's to process and filter data. Remember, in a SAP system, there is one Database while there can be multiple Application Servers, so be kind to your only Database. Let the application servers do the work.
The following quick check list will help you to keep database performance considerations at the forefront of your coding practices. These suggestions will undoubtedly contribute to better performing programs and overall system performance. Integrating these considerations into your daily routine will directly reflect your technical knowledge as a performance programmer.
<b>SQL Quick Checklist</b>
Select Statements within Loop processing is not recommended. Preferred approach is to select data into an itab and then read the itab to access specific records
Do not use Nested Selects, Selects within Loops. or SELECT...ENDSELECT
Do not use Select * unless at least 70% of fields are needed
Select only the fields you require.
Do not use INTO CORRESPONDING
Do not do Order By on non key fields
Force optimizer to use the index where possible
If primary index can not be used, look for alternate indexes or alternate index tables
Avoid Use of LIKE in the Where clause on index fields. It will force a non index read.
Avoid Use of NOT conditions in the Where clause on index fields. It will force a non index read.
Select Single MUST have the primary key fully specified in the WHERE clause. Otherwise use Select.. Up to 1 Rows.
Avoid DISTINCT see performance standards for usage
Consider filtering on the appserver rather than in a WHERE statement
SAP Recommendation on Joins - try not to exceed a 3 Table Join
When using "Select.. For all Entries". The following 4 rules MUST be followed:
o Check to make sure driver itab is not empty
o Always SORT the itab (driver table) by keys. Specify all keys used in the Where clause
o DELETE Adjacent Duplicates Comparing the keys that were sorted.
o All Primary Key Fields must be in the Select List
<b>reward points to all helpful answers</b>
08-13-2007 1:40 PM
Hi,
Definitely Select* statement makes the performance issue so that you can choose the following ways which it better for performance issues.
- Write the select statement with required field names instead of all fields (*) which avoids the performance issue.
- Along with selected field names you may also take care in where condition: you should use only key fields in the where conditions and also maintain the sequence of key fields which they occurred in table if possible.
- Suppose if you use the non-key fields in where condition it makes lot of performance issues and there is no options to use key-fields then you have to create the secondary index for those non-key fields.
-use binary search concept.
-make proper cleare statement after no long use of internal tables
-avoid the joins concept and use the for all entries syntax etc....
Hope these points will be useful to you avoid the performance issues.
Regards,
Vijay