performance issue!

[Former Member]

how do i improve my codes performance?

LOOP AT bestand.

v_matnr1 = bestand-matnr.

PERFORM f2100_mat_text USING bestand-matnr.

FORM F2100_MAT_TEXT

USING L_F_MATNR TYPE STYPE_MAT_KEY-MATNR.

IF L_F_MATNR NE G_S_MAKT-MATNR. "n451923

• read in table imakt "n451923

READ TABLE G_T_MAKT INTO G_S_MAKT "n451923

WITH KEY MATNR = L_F_MATNR "n451923

BINARY SEARCH. "n451923

"n451923

IF SY-SUBRC <> 0. "n451923

• record not found "n451923

CLEAR G_S_MAKT-MAKTX. "n451923

ENDIF. "n451923

ENDIF. "n451923

ENDFORM. "f2100_mat_text

-

---

PERFORM bin USING bestand-matnr CHANGING v_lgpbe.

FORM bin USING p_bestand_matnr

CHANGING p_v_lgpbe.

SELECT SINGLE lgpbe FROM mard INTO p_v_lgpbe

WHERE matnr = p_bestand_matnr AND

werks = p_werks AND

lgort IN lgort.

ENDFORM. "bin

-

---

PERFORM price USING bestand-matnr CHANGING v_price.

FORM price USING p_bestand_matnr

CHANGING p_v_price.

DATA: wa_mbew TYPE mbew.

SELECT SINGLE * FROM mbew INTO wa_mbew

WHERE matnr = p_bestand_matnr AND

bwkey = p_werks AND

bwtar = ''.

IF wa_mbew-vprsv = 'V'.

p_v_price = wa_mbew-verpr.

ELSEIF wa_mbew-vprsv = 'S'.

p_v_price = wa_mbew-stprs.

ENDIF.

ENDFORM. "price

-

---

READ TABLE imarc WITH KEY matnr = bestand-matnr .

if imarc-matnr = bestand-matnr.

IF bestand-anfmenge <> '0.000' OR bestand-soll <> '0.000' OR

bestand-haben <> '0.000' OR bestand-endmenge <> '0.000' .

v_anfmenge = bestand-anfmenge.

v_soll = bestand-soll.

v_endmenge = bestand-endmenge .

*Quality Calculation Starts

PERFORM QUA_CALCULATION USING BESTAND-MATNR

CHANGING V_MSEG_SUM Q_QUANTITY.

IF NOT r_budat IS INITIAL.

SELECT mseg~matnr mseg~shkzg mkpf~mblnr

mkpf~mjahr mkpf~budat mseg~insmk

mseg~menge mseg~zeile mseg~bwart

mseg~kostl mseg~anln1 mseg~aufnr

FROM mkpf AS mkpf JOIN mseg AS mseg

ON mkpf~mblnr = mseg~mblnr AND mkpf~mjahr = mseg~mjahr

INTO TABLE i_mkpf_mseg "FOR ALL ENTRIES IN bestand

WHERE mseg~werks IN g_ra_werks AND

mseg~lgort in lgort AND

mseg~matnr = p_matnr AND

mkpf~budat IN r_budat.

if sy-subrc eq 0.

i_new_mkpf_mseg-matnr = p_matnr.

LOOP AT i_mkpf_mseg.

IF i_mkpf_mseg-bwart NE '321' AND i_mkpf_mseg-insmk EQ 'X'

AND i_mkpf_mseg-shkzg = 'S'.

v_mseg_sum1 = v_mseg_sum1 + i_mkpf_mseg-menge.

ELSEIF i_mkpf_mseg-bwart NE '321' AND i_mkpf_mseg-insmk EQ 'X'

AND i_mkpf_mseg-shkzg = 'H'.

v_mseg_sum2 = v_mseg_sum2 + i_mkpf_mseg-menge.

ELSEIF

i_mkpf_mseg-bwart EQ '321' AND i_mkpf_mseg-shkzg = 'H'.

v_mseg_sum3 = v_mseg_sum3 + i_mkpf_mseg-menge.

ENDIF.

AT END OF matnr.

v_mseg_sum = v_mseg_sum1 - v_mseg_sum2 - v_mseg_sum3.

p_v_mseg_sum = v_mseg_sum.

CLEAR: i_mkpf_mseg,i_new_mkpf_mseg,v_mseg_sum1,

v_mseg_sum2,v_mseg_sum3.

ENDAT.

ENDLOOP.

endif.

ENDIF.

• Selecting Entries from Mardh

• Even if we don't get data from mseg mkpf we have to pick the entries

• from mardh and mard.

SELECT * FROM mardh INTO CORRESPONDING

FIELDS OF TABLE i_new_mardh WHERE

matnr = P_MATNR AND werks = p_werks

AND lfgja EQ v_year AND lfmon GE v_month and lgort in lgort.

IF sy-subrc EQ 0.

• picking the quality for all storage locations ( Without Repeated

• entrie ) .

LOOP AT i_new_mardh.

v_insme = i_new_mardh-insme.

AT NEW lgort.

i_lgort-lgort = i_new_mardh-lgort.

APPEND i_lgort.

q_quantity = q_quantity + v_insme.

CLEAR v_insme.

CLEAR i_lgort.

ENDAT.

endloop.

CLEAR: i_new_mardh, i_new_mardH[].

endif.

• 1.Even if we don't get any value from mardh we have to select the

• entries in mard

• 2.Selecting Entries from Mard

SELECT * FROM mard INTO CORRESPONDING

FIELDS OF TABLE i_new_mard WHERE

matnr = p_matnr AND werks = p_werks AND

lfgja EQ v_year and lgort in lgort.

if sy-subrc eq 0.

• picking the quality for all available diff. storage locations

• except the ones which are there in mardh.

LOOP AT i_lgort.

LOOP AT i_new_mard.

IF i_new_mard-lgort = i_lgort-lgort.

DELETE i_new_mard.

ENDIF.

ENDLOOP.

CLEAR I_NEW_MARD.

ENDLOOP.

LOOP AT i_new_mard .

IF i_new_mard-lfmon LT v_cmonth.

v_insme = i_new_mard-insme.

AT NEW lgort.

q_quantity = q_quantity + v_insme.

CLEAR v_insme.

ENDAT.

ENDIF.

ENDLOOP.

ENDIF.

CLEAR i_lgort.

CLEAR i_lgort[].

p_q_quantity = Q_QUANTITY.

CLEAR: i_new_mard,i_new_mard[].

ENDFORM. " QUA_CALCULATION

-

---

*Quality Calculation Ends

v_quality = Q_QUANTITY + V_MSEG_SUM.

v_endwert = V_ENDMENGE * V_PRICE.

v_total_quality = v_total_quality + v_quality.

v_unres = v_endmenge - v_quality.

v_total_unres = v_total_unres + v_unres.

v_op_stock_sum = v_op_stock_sum + v_anfmenge.

v_rcvd_sum = v_rcvd_sum + v_soll .

v_issued_sum = v_issued_sum + bestand-haben .

v_bestand-endmenge = v_bestand-endmenge + v_endmenge .

v_cl_stock_sum = v_cl_stock_sum + v_endwert.

-

---

regards

Essam

essamsaud@yahoo.co.in

[Former Member]

Hi Essam,

Have you checked in SE30 and ST05 as which piece of your code is taking more time. I think by doing this you can improve the code on your own.

Regards,

Atish

[Former Member]

Hi Essam Khan,

Try writing the perform statement before the loop. If it is in the loop it will hit the database no of times and reduce the performance.

Regards,

Nagaraju.

[Former Member]

1. loop inside a loop is a strict no no..

2. write the performs outside the loop..

3. <b>Performs having SELECT stmt shud never be inside the loop..</b>

4. All READ stmts shud hav a <b>TRANSPORTING NO FIELDS</b>

Reward if helpful

[Former Member]

Hi Khan,

First you need to try to avoid select statements within loop,

second one dont use INTO CORRESPONDING stataement and also try to avoid SELECT * statement so the you can improve the perforamnce wise good.

i tried to sort out the some of select statements so you can use the following piece of code according to ur convienience.

If not bestand[] is initial.

SELECT matnr lgpbe FROM mard INTO tbl_v_lgpbe

WHERE matnr = bestand_matnr AND

werks = p_werks AND

lgort IN lgort.

sort tbl_v_lgpbe by matnr.

SELECT matnr verpr vprsv FROM mbew INTO tbl_mbew

WHERE matnr = p_bestand_matnr AND

bwkey = p_werks AND

bwtar = ''.

sort tbl_mbew by matnr.

endif. etc.............

now you can use this internal tables in loop by using READ statement.

in your code also try to avoid the joins and loop inside loop---- i think this statements giving big performance isses bec mseg contain lot of data and angin you put this joins select stament with in loop.

Here you can follow the some of tips while writing select statements and internal tables.

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.

<b>Internal Table Quick Checklist</b>

• 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

<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 with points if useful.</b>

Regards,

Vijay

[Former Member]

Hi Mr:Khan,

First of all we need to avoid DB hits from the loop, for this you can use Select <b>for all entries</b> bestand with corresponding conditions, for ex:

SELECT lgpbe FROM mard INTO table it_mard

FOR ALL entries of bestand

WHERE matnr = bestand_matnr AND

werks = p_werks AND

lgort IN lgort.

Similarly do all the select statement from diffrent diffrent Database tables, and make it available in corresponding interanl tables.

Now you can start your loop, and whatever data you want is now available in diffrent internal tables,use READ statments for ex: read it_amrd into wa_mard where matnr = wa_bestand-matnr.

This will be a more effective way, you can try this way and can avoid so much DB hitting which in turn increase the performane of your code,

Good luck!

Regards

Antony Thomas

[Former Member]

Hi

<b>Ways of Performance Tuning</b>

1. Selection Criteria

2. Select Statements

• Select Queries

• SQL Interface

• Aggregate Functions

• For all Entries

Select Over more than one Internal table

<b>Selection Criteria</b>

1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.

2. Select with selection list.

<b>Points # 1/2</b>

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

<b>Select Statements Select Queries</b>

1. Avoid nested selects

2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.

3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.

4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.

5. Use Select Single if all primary key fields are supplied in the Where condition .

<b>Point # 1</b>

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.

<b>Point # 2</b>

SELECT * FROM SBOOK INTO SBOOK_WA.

CHECK: SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

ENDSELECT.

The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table

SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK

WHERE SBOOK_WA-CARRID = 'LH' AND

SBOOK_WA-CONNID = '0400'.

<b>Point # 3</b>

To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.

<b>Point # 4</b>

SELECT * FROM SBOOK INTO SBOOK_WA

UP TO 1 ROWS

WHERE CARRID = 'LH'.

ENDSELECT.

The above code is more optimized as compared to the code mentioned below for testing existence of a record.

SELECT * FROM SBOOK INTO SBOOK_WA

WHERE CARRID = 'LH'.

EXIT.

ENDSELECT.

<b>Point # 5</b>

If all primary key fields are supplied in the Where condition you can even use Select Single.

Select Single requires one communication with the database system, whereas Select-Endselect needs two.

<b>Select Statements contd.. SQL Interface</b>

1. Use column updates instead of single-row updates

to update your database tables.

2. For all frequently used Select statements, try to use an index.

3. Using buffered tables improves the performance considerably.

<b>Point # 1</b>

SELECT * FROM SFLIGHT INTO SFLIGHT_WA.

SFLIGHT_WA-SEATSOCC =

SFLIGHT_WA-SEATSOCC - 1.

UPDATE SFLIGHT FROM SFLIGHT_WA.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

UPDATE SFLIGHT

SET SEATSOCC = SEATSOCC - 1.

<b>Point # 2</b>

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

The above mentioned code can be more optimized by using the following code

SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA

WHERE MANDT IN ( SELECT MANDT FROM T000 )

AND CARRID = 'LH'

AND CONNID = '0400'.

ENDSELECT.

<b>Point # 3</b>

Bypassing the buffer increases the network considerably

SELECT SINGLE * FROM T100 INTO T100_WA

BYPASSING BUFFER

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

The above mentioned code can be more optimized by using the following code

SELECT SINGLE * FROM T100 INTO T100_WA

WHERE SPRSL = 'D'

AND ARBGB = '00'

AND MSGNR = '999'.

<b>Select Statements contd… Aggregate Functions</b>

• If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.

Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )

Consider the following extract.

Maxno = 0.

Select * from zflight where airln = ‘LF’ and cntry = ‘IN’.

Check zflight-fligh > maxno.

Maxno = zflight-fligh.

Endselect.

The above mentioned code can be much more optimized by using the following code.

Select max( fligh ) from zflight into maxno where airln = ‘LF’ and cntry = ‘IN’.

<b>Select Statements contd…For All Entries</b>

• 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)

<u>Points to be must considered FOR ALL ENTRIES • Check that data is present in the driver table</u>• Sorting the driver table

• Removing duplicates from the driver table

Consider the following piece of extract

Loop at int_cntry.

Select single * from zfligh into int_fligh

where cntry = int_cntry-cntry.

Append int_fligh.

Endloop.

The above mentioned can be more optimized by using the following code.

Sort int_cntry by cntry.

Delete adjacent duplicates from int_cntry.

If NOT int_cntry[] is INITIAL.

Select * from zfligh appending table int_fligh

For all entries in int_cntry

Where cntry = int_cntry-cntry.

Endif.

<b>Select Statements contd… Select Over more than one Internal table</b>

1. Its better to use a views instead of nested Select statements.

2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.

3. Instead of using nested Select loops it is often better to use subqueries.

<b>Point # 1</b>

SELECT * FROM DD01L INTO DD01L_WA

WHERE DOMNAME LIKE 'CHAR%'

AND AS4LOCAL = 'A'.

SELECT SINGLE * FROM DD01T INTO DD01T_WA

WHERE DOMNAME = DD01L_WA-DOMNAME

AND AS4LOCAL = 'A'

AND AS4VERS = DD01L_WA-AS4VERS

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

The above code can be more optimized by extracting all the data from view DD01V_WA

SELECT * FROM DD01V INTO DD01V_WA

WHERE DOMNAME LIKE 'CHAR%'

AND DDLANGUAGE = SY-LANGU.

ENDSELECT

<b>Point # 2</b>

SELECT * FROM EKKO INTO EKKO_WA.

SELECT * FROM EKAN INTO EKAN_WA

WHERE EBELN = EKKO_WA-EBELN.

ENDSELECT.

ENDSELECT.

The above code can be much more optimized by the code written below.

SELECT P_{F1 P}F2 F_{F3 F}F4 INTO TABLE ITAB

FROM EKKO AS P INNER JOIN EKAN AS F

ON P_{EBELN = F}EBELN.

<b>Point # 3</b>

SELECT * FROM SPFLI

INTO TABLE T_SPFLI

WHERE CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK'.

SELECT * FROM SFLIGHT AS F

INTO SFLIGHT_WA

FOR ALL ENTRIES IN T_SPFLI

WHERE SEATSOCC < F~SEATSMAX

AND CARRID = T_SPFLI-CARRID

AND CONNID = T_SPFLI-CONNID

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

The above mentioned code can be even more optimized by using subqueries instead of for all entries.

SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA

WHERE SEATSOCC < F~SEATSMAX

AND EXISTS ( SELECT * FROM SPFLI

WHERE CARRID = F~CARRID

AND CONNID = F~CONNID

AND CITYFROM = 'FRANKFURT'

AND CITYTO = 'NEW YORK' )

AND FLDATE BETWEEN '19990101' AND '19990331'.

ENDSELECT.

<b>Internal Tables</b>

1. Table operations should be done using explicit work areas rather than via header lines.

2. Always try to use binary search instead of linear search. But don’t forget to sort your internal table before that.

3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.

4. A binary search using secondary index takes considerably less time.

5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.

6. Modifying selected components using “ MODIFY itab …TRANSPORTING f1 f2.. “ accelerates the task of updating a line of an internal table.

<b>Point # 2</b>

READ TABLE ITAB INTO WA WITH KEY K = 'X‘ BINARY SEARCH.

IS MUCH FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY K = 'X'.

If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).

<b>Point # 3</b>

READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING

READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.

<b>Point # 5</b>

LOOP AT ITAB INTO WA WHERE K = 'X'.

" ...

ENDLOOP.

The above code is much faster than using

LOOP AT ITAB INTO WA.

CHECK WA-K = 'X'.

" ...

ENDLOOP.

<b>Point # 6</b>

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.

The above code is more optimized as compared to

WA-DATE = SY-DATUM.

MODIFY ITAB FROM WA INDEX 1.

7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably

8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.

9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to “ LOOP-APPEND-ENDLOOP.”

10. “DELETE ADJACENT DUPLICATES“ accelerates the task of deleting duplicate entries considerably as compared to “ READ-LOOP-DELETE-ENDLOOP”.

11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to “ DO -DELETE-ENDDO”.

<b>Point # 7</b>

Modifying selected components only makes the program faster as compared to Modifying all lines completely.

e.g,

LOOP AT ITAB ASSIGNING <WA>.

I = SY-TABIX MOD 2.

IF I = 0.

<WA>-FLAG = 'X'.

ENDIF.

ENDLOOP.

The above code works faster as compared to

LOOP AT ITAB INTO WA.

I = SY-TABIX MOD 2.

IF I = 0.

WA-FLAG = 'X'.

MODIFY ITAB FROM WA.

ENDIF.

ENDLOOP.

<b>Point # 8</b>

LOOP AT ITAB1 INTO WA1.

READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.

IF SY-SUBRC = 0.

ADD: WA1-VAL1 TO WA2-VAL1,

WA1-VAL2 TO WA2-VAL2.

MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.

ELSE.

INSERT WA1 INTO ITAB2 INDEX SY-TABIX.

ENDIF.

ENDLOOP.

The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by

LOOP AT ITAB1 INTO WA.

COLLECT WA INTO ITAB2.

ENDLOOP.

SORT ITAB2 BY K.

COLLECT, however, uses a hash algorithm and is therefore independent

of the number of entries (i.e. O(1)) .

<b>Point # 9</b>

APPEND LINES OF ITAB1 TO ITAB2.

This is more optimized as compared to

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

<b>Point # 10</b>

DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.

This is much more optimized as compared to

READ TABLE ITAB INDEX 1 INTO PREV_LINE.

LOOP AT ITAB FROM 2 INTO WA.

IF WA = PREV_LINE.

DELETE ITAB.

ELSE.

PREV_LINE = WA.

ENDIF.

ENDLOOP.

<b>Point # 11</b>

DELETE ITAB FROM 450 TO 550.

This is much more optimized as compared to

DO 101 TIMES.

DELETE ITAB INDEX 450.

ENDDO.

12. Copying internal tables by using “ITAB2[ ] = ITAB1[ ]” as compared to “LOOP-APPEND-ENDLOOP”.

13. Specify the sort key as restrictively as possible to run the program faster.

<b>Point # 12</b>

ITAB2[] = ITAB1[].

This is much more optimized as compared to

REFRESH ITAB2.

LOOP AT ITAB1 INTO WA.

APPEND WA TO ITAB2.

ENDLOOP.

<b>Point # 13</b>“SORT ITAB BY K.” makes the program runs faster as compared to “SORT ITAB.”

<b>Internal Tables contd…

Hashed and Sorted tables</b>

1. For single read access hashed tables are more optimized as compared to sorted tables.

2. For partial sequential access sorted tables are more optimized as compared to hashed tables

Hashed And Sorted Tables

<b>Point # 1</b>

Consider the following example where HTAB is a hashed table and STAB is a sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE HTAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

This runs faster for single read access as compared to the following same code for sorted table

DO 250 TIMES.

N = 4 * SY-INDEX.

READ TABLE STAB INTO WA WITH TABLE KEY K = N.

IF SY-SUBRC = 0.

" ...

ENDIF.

ENDDO.

<b>Point # 2</b>

Similarly for Partial Sequential access the STAB runs faster as compared to HTAB

LOOP AT STAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

This runs faster as compared to

LOOP AT HTAB INTO WA WHERE K = SUBKEY.

" ...

ENDLOOP.

<b>Reward if usefull</b>