Performance problem with abap code

[Former Member]

Hi,

I'm facing problems with a FI report. The batch job took approx 4hours for one variant and some variants can't even complete on time. For this case, out of the 4hrs, only 1 hour is due to SQL access.

I've traced the 3hr performance problem to a form which does calculation and sum of figures within loops.

What could be the problem... or what would be a good way to further investigate this?

So far I have only done performance tuning for programs due to inefficient SQL statements.

So, this is something new to me.

Thanks!

[Former Member]

any experts in this area?

[Former Member]

anyone? i'll reward generously. thanks!

[Former Member]

read is not the problem. it doesnt use read.

some of the key abap used are:

within loop. ..

at new.

sum

compute

modify

what can cause several hours of processing?

any experts? i'll reward generously. thanks.

[Former Member]

hi

loops within loop mite be one cause...

chk the link below:

https://wiki.sdn.sap.com/wiki/display/HOME/ABAPPerformanceand+Tuning

if possible post ur code here...

regards,

madhu

[Former Member]

Hi,

There can be many reason why your program is running for too long. Is there any way you can post your code here. This will be helpful to find the root cause.

Regards,

RS

[Former Member]

Key things to check:

1. Is the internal table sorted before the Loop.

2. Are nested loops used in the code - I feel that this is causing an issue.

3. Usage of Control break statements in nested loops to be avoided.

4. Selects within Loop are to be avoided.

The above are the most common things that hinder the performace of the reports.

Naveen.

[Former Member]

found something interesting...

it's something to do with this code..

& i think is the get time field

FORM timestamp  USING    value(itext) TYPE c.
  GET TIME FIELD ts-uzeit.
  MOVE sy-datum TO ts-datum.
  MOVE itext TO ts-event.
  APPEND ts. CLEAR ts.

  IF sy-batch EQ x
  OR write_ts EQ x.
    MESSAGE s020(nn) "&
     WITH itext.
  ENDIF.
ENDFORM.                    " timestamp

[christian_wohlfahrt]

Hi Charles!

This routine looks completely harmless. I just made a runtime analysis, in my system get time field needs 15 microseconds - nothing you have to worry about. Maybe for large tables TS the append needs sometimes a little bit longer - when new memory has to be allocated, but usually finding the values to be stored in an internal table takes longer than appending the table.

Either you post bigger parts of the code, or you have to go on in your search for slow code.

Regards,

Christian

[Former Member]

Hi Christian,

It is indeed this part that is causing the problem.

It is very surprising to me as well.

I wonder why the programmer uses get time field...

why not just assign sy-uzeit to the itab field...

even though the program may run pass midnight. the date value should be correct as well...

so why need get time field?

for a 15 minutes program.. this form is used 8 times. but only one part is causing problem

it took 7 minutes! that part is not within a loop.

Thanks,

Charles

[christian_wohlfahrt]

Hi Charles,

to your question: why get time field at all?

The time fields sy-uzeit and sy-datum are only updated in the beginning of a report (not every second) - and with the explicit command get time.

To avoid long running programs, which update DB with one single timestamp, a get time makes sense and is used to get different times for the DB.

As this usually takes only some microseconds, the usage is normally not a topic of discussion. Sounds more like the side-effect from a totally different problem, like swaping or network or anything else (I don't have an idea, what might cause get time to stop for minutes).

How did you come to the conclusion, get time needed 7 minutes?

Regards,

Christian

[Former Member]

Hi Christian,

I coded sy-uzeit to output at different points... so that i know how much time is taken for each part of the program.

sy-uzeit does changes... not only at the beginning of the report.

[Former Member]

Run the report .

Execute transaction sm50 . select the thread u are running and then go to menu program mode -> program -> debugging . This will lead u into the code where u can then check if there is a loop in the code or if a read etc is causing issues .

The transaction will also show u the time it takes for individual selects . keep pressing F8 on the transaction and you can see the selects whizzing by on the right hand side .

[Former Member]

narrowed down to:

IF sy-batch EQ x OR write_ts EQ x.

MESSAGE s020(nn) WITH itext.

ENDIF.

what's wrong with this. if it is a background job... it do this messaging a few time?

[christian_wohlfahrt]

Hi Charles,

there are a few commands updating the time fields (maybe commit work - but after the table values are set, so of no use for the right entries in the table) - in general it's not reliable for time measurements with get time - command.

What are you doing, when 'narrowing done' - I have the feeling, you are pointing at random places. E.g. when you debug and you have a long wait time for the if-statement (or the message s...), then it's maybe just a slow network connection and you are waiting 99% for GUI - which has absolutely nothing to do with runtime in background.

Run a runtime analysis (SE30), write details to modularisation units and check for large net times (if more than 50% is ABAP and not DB). This should lead you to the right place. Also gathering data for internal tables is usefull - you might be right about this guess.

Regards,

Christian

[Former Member]

Just to add.. Too many decimal places can also lead to high ABAP time...also considering all this computing is done within loops.

Also check if you can modify or delete multiple lines at a time rather than doing it line by line.