How to performance tune this code ?

[Former Member]

Believe this function module is performance tuned, Any suggestions how to improve the code. Any suggestions appreciated..

Thanks in Advance,

BWer

FUNCTION ZCPMHIERTEST.

*"----

---

""Local interface:

*" IMPORTING

*" REFERENCE(IOB_NAME) TYPE C

*" REFERENCE(HIER_NAME) TYPE C OPTIONAL

*" EXPORTING

*" REFERENCE(HIER_OUT) LIKE ZHIERAR_TAB STRUCTURE ZHIERAR_TAB

*"----

---

DATA: hier_tab_name(36) type C,

int_tab_name(36) type C,

text_tab_name(36) type C,

iob_name_cap(30) type C,

h_itab like hier_out occurs 0 with header line,

h_wa like h_itab.

iob_name_cap = iob_name.

• convert to upper case

TRANSLATE IOB_NAME_cap to UPPER CASE.

• find if custom infobject or not

if iob_name+0(1) = 'Z' or

iob_name+0(1) = 'z'.

hier_tab_name = '/BIC/H' + iob_name.

int_tab_name = '/BIC/J' + iob_name.

text_tab_name = '/BIC/T' + iob_name.

else.

hier_tab_name = '/BI0/H' + iob_name.

int_tab_name = '/BIO/J' + iob_name.

text_tab_name = '/BIO/T' + iob_name.

endif.

• Get hierarchy table data

select HIEID NODEID IOBJNM NODENAME TLEVEL PARENTID CHILDID NEXTID

INTERVL from (hier_tab_name)

into table h_itab

where OBJVERS = 'A'.

sort h_itab by HIEID NODEID.

loop at h_itab.

move-corresponding h_itab to h_wa.

• fill leaf info

select single LEAFFROM LEAFTO

from (int_tab_name)

into corresponding fields of h_wa

where HIEID = h_wa-HIEID

and NODEID = h_wa-NODEID

and OBJVERS = 'A'.

• fill text info

if h_wa-CHILDID eq '00000000'.

select single TXTSH TXTMD TXTLG

from (text_tab_name)

into corresponding fields of h_wa

where HIEID = h_wa-HIEID

and NODEID = h_wa-NODEID

and OBJVERS = 'A'.

else.

select single TXTSH TXTMD TXTLG

from RSTHIERNODE

into corresponding fields of h_wa

where HIEID = h_wa-HIEID

and NODENAME = h_wa-NODEID

and OBJVERS = 'A'.

endif.

• update the output table.

modify h_itab from h_wa

transporting LEAFFROM LEAFTO TXTSH TXTMD TXTLG.

endloop.

ENDFUNCTION.

[Former Member]

Does it execute without dumping?

Rob

[Former Member]

The reason I ask is that the statement:

hier_tab_name = '/BIC/H' + iob_name.

will cause you program to crash. Do you mean to do an addition, or are you trying to concatenate? If you want to concatenate the two fields, the syntax is:

concatenate '/BIC/H' iob_name into hier_tab_name.

Rob

[Former Member]

yes i have changed that statement.. and replaced it by concatenate

concatenate '/BIC/H' iob_name into hier_tab_name.

[Former Member]

One more thing - If you move the definition of h_itab to the top include, the data from the last execution of the FM will remain in the table for successive calls to the FM from within a program.

So, if the FM is called multiple times by a program (in a loop, say) you can first check to see if the records you need are already there. If they are, you can get them from the internal table; otherwise, retrieve the records you want and append the table.

Rob

[Former Member]

hi, avoid using INTO CORRESPONDING FIELDS OF, if possible.

you can define some temp structure for store the select result, and set them into your 'H_WA', when you do modify at last.

If should be useful to upgrade your performance.

If it is not enough, you can move the select from the LOOP, select all of the entries before LOOP, and just read internal table in the LOOP, in order to reduce the access time to DB.

But effect of this solution is due to the amount of your data.

thanks a lot

[Former Member]

ya....instead of using into corresponding fields....if it is possible for you to have the fields of the internal table in the same order as specified in the select query then u can simply use into table....if there are additional fields, they can come at the end....this will lead to a much improved performance of the select query

regards,

PJ

[christian_wohlfahrt]

Hi BWer,

I a bit confused: should I believe, it is performance tuned (no changes to selects), or make some comments?

Anyway, here some comments:

I think, you can save some time by an optimized access instead of select singles. Instead you can read all relevant entries at once - with 'for all entries'.

Create 4 additional internal tables: 2 for the where-clause, 2 for the select result.

Collect HIEID NODEID depending on CHILDID into on or the other table.

After endloop, make two selects for the corresponding tables. Fetch in addition HIEID NODEID.

In a new loop, make read table statements instead of select singles. Use internal tables of hashed type -> you can use a key access.

But if the runtime of the select singles is less then - let's say 15%, forgot the option.

Regards,

Christian