topic Program is too much time for Execution in Application Development and Automation Discussions

Program is too much time for Execution

Former Member — Mon, 13 Aug 2007 09:46:01 GMT

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

Re: Program is too much time for Execution

Former Member — Mon, 13 Aug 2007 10:26:30 GMT

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

Re: Program is too much time for Execution

Former Member — Mon, 13 Aug 2007 10:29:25 GMT

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 isn’t 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.

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

Re: Program is too much time for Execution

Former Member — Mon, 13 Aug 2007 10:52:17 GMT

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

Re: Program is too much time for Execution

suredarreddy_pulimamidi — Mon, 13 Aug 2007 11:04:28 GMT

hi,

fallow my tips these are related to performance maximum of the time performance of the program will depends on the declaration of the internal tables and writing select statements.

for this use the fallowing tips :

Internal Tables

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.

SQL Quick Checklist

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

reward points to all helpful answers

Re: Program is too much time for Execution

Former Member — Mon, 13 Aug 2007 12:40:35 GMT

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