2009 Jun 05 9:28 AM
Hello,
I have a custom program (programmed by somebody else) which is churning away all day long and consuming between 50% and 70% CPU as seen in the 'top' command. I'm on HP-UX with 8 CPUs installed. The CPU usage is consistently at this level. (I matched the PID from SM50 with the PID in 'top')
I ran abap traces in ST12 which found that between 60% and 70% of the time was spent in the following coding:
773 IF SY-SUBRC <> 0.
774 LOOP AT GIT_ZTABLEA TRANSPORTING NO FIELDS
775 WHERE KUNNR = PC_KUNNR "CUSTOMER CODE゙
776 AND ZZVCGRTNFG IN P_DRTNFG "FLAG゙(SELECTION CRITEREA)
777 AND ZZVCGSTPFG IN P_DSPDFG . "QUIT FLAG゙(SELECTION CRITEREA)
778 EXIT.
779 ENDLOOP .
780
781 *
782 PI_SUBRC = SY-SUBRC .
783 RETURN .
784
785 *
786 ELSE.
787 LOOP AT GIT_ZTABLEA TRANSPORTING NO FIELDS
788 WHERE ZZVCGGRPID = GFC_TABLEB-ZZVCGGRPID "GROUP ID
789 AND ZZVCGRTNFG IN P_DRTNFG "FLAG゙(SELECTION CRITEREA)
790 AND ZZVCGSTPFG IN P_DSPDFG. "STOP FLAG゙(SELECTION CRITEREA)
791 EXIT.
792 ENDLOOP .
I guess the idea here is to just find the number of rows in GIT_ZTABLEA for certain conditions.
Is there a simple and less intensive way of achieving this?
(apologies in advance for foreseen dumb questions. I'm very new to coding).
Peter
2009 Jun 08 11:11 AM
> ya both your and my code is wrong i guess coz even in yours the index is not updated and
> after looking at the main code again i think this will be the correct code
nonsense, my code is correct, while yours is still wrong
You aussume that both tables are sorted in the same way and that both contain the same keys,
both anssumptions are wrong!
If a record is missing then you will never determine a new index!
The READ BINARY SEARCH determines the index, and that is the main point of the optimization.
Please think twice before you want to correct me.
Siegfried
2009 Jun 05 9:43 AM
use internal table of type sorted
for your loop that will reduce cpu usage
Regards,
Alpesh
2009 Jun 05 2:03 PM
> LOOP AT GIT_ZTABLEA TRANSPORTING NO FIELDS
> 775 WHERE KUNNR = PC_KUNNR "CUSTOMER CODE゙
> 776 AND ZZVCGRTNFG IN P_DRTNFG "FLAG゙(SELECTION CRITEREA)
> 777 AND ZZVCGSTPFG IN P_DSPDFG . "QUIT FLAG゙(SELECTION CRITEREA)
sorted table ... is the usual answer but not in this case.
You should check the IN P_DRTNFG "FLAG゙(SELECTION CRITEREA) ?
What does it mean? I don`t undterstand the flag.
With the IN conditions I doubt that there is any optimziation possible, it will always scan.
If the two IN-flag are really flags then it should be possible to write equal condition
and get something
WHERE k = a AND z1 = b AND z2 = c.
The can be solved with sorted tables.
And from the coding you show with will exit after the first solution, so a READ would then also
be enough. The LOOP is only used because the WHERE is only possible with the LOOP.
but a LOOP is not really necessary because it check only the first solution.
So please revise the logic.
Then it will become really fast.
Siegfried
2009 Jun 05 2:26 PM
Is this code called from within a loop or is it in a form called from within a loop?
Rob
2009 Jun 07 12:01 AM
Hi,
i am a bit confused about the IN statements. The fields are describes as Flag, a flag is usually yes or no why using an in statement there?
Furthermore sorting the table could add to performance if the table is sorted by customer code as sorted tables look for the start dataset in binary search when the key or a key part is specified.
Rgds.
Roman
2009 Jun 07 4:32 PM
that is the more general case of a often repeated recommendation.
sort GIT_ZTABLEA by ZZVCGGRPID.
....
read table GIT_ZTABLEA transporting no fields
with key ZZVCGGRPID = GFC_TABLEB-ZZVCGGRPID.
IDX = SY-TABIX.
loop at GIT_ZTABLEA into WA from index IDX
if ( WA-ZZVCGGRPID = GFC_TABLEB-ZZVCGGRPID
and WA-ZZVCGRTNFG IN P_DRTNFG
and WA-ZZVCGSTPFG IN P_DSPDFG ).
* success -> exit ???
endif.
if not ( WA-ZZVCGGRPID = GFC_TABLEB-ZZVCGGRPID.
exit.
endif.
endloop.
there is something missing, in your posting, you don't discriminate between the cae where something is found and nothing is found
Siegfried
2009 Jun 08 6:43 AM
you can replace the above code like this but the thing is i dont see you keeping any record with any of these loops.
data: lv_index1 type sy-index,
lv_index2 type sy-index.
sort GIT_ZTABLEA by KUNNR ZZVCGRTNFG ZZVCGSTPFG
loop at GIT_ZTABLEA from lv_index1.
if GIT_ZTABLEA-KUNNR = PC_KUNNR or ZZVCGRTNFG in GIT_ZTABLEA or ZZVCGSTPFG in GIT_ZTABLEA.
lv_index1 = sy-index.
exit.
endif.
endloop.Nafran.
2009 Jun 08 7:37 AM
> you can replace the above code like this but
no, he can't oyur solution is simply wrong!
2009 Jun 08 9:45 AM
ya both your and my code is wrong i guess coz even in yours the index is not updated and after looking at the main code again i think this will be the correct code
data: lv_index1 type sy-index,
lv_index2 type sy-index.
sort GIT_ZTABLEA by KUNNR ZZVCGRTNFG ZZVCGSTPFG
loop at GIT_ZTABLEA from lv_index1.
if ( GIT_ZTABLEA-KUNNR = PC_KUNNR and ZZVCGRTNFG in GIT_ZTABLEA and ZZVCGSTPFG in GIT_ZTABLEA. )
lv_index1 = sy-index.
exit.
endif.
endloop.
2009 Jun 08 11:11 AM
> ya both your and my code is wrong i guess coz even in yours the index is not updated and
> after looking at the main code again i think this will be the correct code
nonsense, my code is correct, while yours is still wrong
You aussume that both tables are sorted in the same way and that both contain the same keys,
both anssumptions are wrong!
If a record is missing then you will never determine a new index!
The READ BINARY SEARCH determines the index, and that is the main point of the optimization.
Please think twice before you want to correct me.
Siegfried
2009 Jun 08 11:46 AM
Thank you all. Even the "not so good" advice has been great.
It's good to know that the code does have room for improvement; it will take me some time to understand all the advice however I got exactly what I was looking for.