abap perf tuning.

[Former Member]

Hi,

I came across the article where it was mentioned that following steps to follow while doing abap performance tuning.

1) Try to reduce I/O first, then memory, then CPU activity.

I/O operations : Read / Write to hard disk.

2) Memory : if not controlled, may have to be written to swap space on the hard disk. (Check the system installation what is

the maximum memory that internal table can occupy)

3) CPU : Careful program design

First point I understood, but 2nd and 3rd i have not. how to control memory and what careful program design will reduce CPU?

Regards,

Santosh

[Former Member]

Hi,

I came across the article where it was mentioned that following steps to follow while doing abap performance tuning.

1) Try to reduce I/O first, then memory, then CPU activity.

I/O operations : Read / Write to hard disk.

2) Memory : if not controlled, may have to be written to swap space on the hard disk. (Check the system installation what is

the maximum memory that internal table can occupy)

3) CPU : Careful program design

First point I understood, but 2nd and 3rd i have not. how to control memory and what careful program design will reduce CPU?

Regards,

Santosh

[Former Member]

Hi,

ad. 2.

Example: you call routine and pass large internal table as an argument. You can pass it as a reference (correct, fast, low memory size is used) or by value (not efficient, system copies whole table - which you mainly use for reading, not modifying). In most cases you should use pass by reference.

ad. 3.

Example: you have 2 internal tables and for every row in itab1 you find corresponding row in itab2. You can do LOOP AT itab2 inside LOOP AT itab1 and make system to check a lot of unnecessary amount of data (it takes lot of time). Or you can do READ TABLE itab2 (especially, when itab2 is hashed or sorted table) inside LOOP AT itab1. This will not be time consuming. In most cases you should avoid nested loops.

Regards,

--

Przemysław

[Former Member]

Hhhmmm, hard to comment on those very generic points. However, I'd say that this sounds a bit suspicious. Any performance tuning usually starts with a proper analysis to find out which resources are the bottleneck. Once you've identified the problematic areas you can start with the performance tuning.

The problem with performance tuning is that there's so many different aspects to it. E.g. from a system perspective we would like to have a high throughput, whereas from a user perspective short response times are probably the main focus.

E.g. let's say we create a data extract and have a program that reads first all the required data from the database into an internal table (i.e. has to be stored in memory). This is bound to cause problems, because all of a sudden you end up with one work process eating up huge amounts of data and thus possibly creating a memory bottleneck (meaning other users/processes having possibly less memory available and possibly the start of swapping). In such a case it's probably a better design to read the data in chunks and then write those data chunks to the extract.

So my example tries to address the second point. Basically I'd say they're trying to say that once you occupy too much memory the OS will start swapping (i.e. mapping memory areas from RAM to disk), which is very slow (memory access is fast, disk IO slow).

A waste of CPU time is for example caused by lookups in huge internal ABAP tables without an efficient access (e.g. binary search due to sorted table or access via hash keys).