Regarding the run time analysis

[rohit_kaikala]

Hi All,

To check the performance of the program, we will go to Run time analysis, in the utilities. In the analyes part consist of graphical representation of the ABAP, DATABASE and System.

My Question is 'When we give small range of values in the Selection screen then the database hit is less, but when we give large range of values then database hit is more'.

So how to analyse the program performance in the scenario?

Please reply,

Thanks,

Rohit.

[rohit_kaikala]

Hi All,

To check the performance of the program, we will go to Run time analysis, in the utilities. In the analyes part consist of graphical representation of the ABAP, DATABASE and System.

My Question is 'When we give small range of values in the Selection screen then the database hit is less, but when we give large range of values then database hit is more'.

So how to analyse the program performance in the scenario?

Please reply,

Thanks,

Rohit.

[Former Member]

Hi,

say for example for a 2 day date range , u might get 10 records from a table, but for 1 month date range u might get 1000 records from the same table.

this all depends on your requirement.

to improvise in that case, with that large range of input, run st05

and find the sql statements which can be improved further.

analyse the tables which you are using in your program. see if you are using key fields to retrieve data. find the possibilities to restrict the data.

there are documentations availabe in SDN reg. SE30, ST05 and other tools.

regards,

madhu

[Former Member]

Rohit,

this is obvious thing when you ran for smaller range than some few records may fetch from DB than impact on DB also very less .

so better you goto ST05 and correct your SQL statements and remove the unnessarry loops from PRG.

Amit.

[alison_lloyd]

You should run for both a few records and a large volume - few records should also imply not much ABAP processing

[Former Member]

that is exactly the point:

Check SQL Trace first,

SQL trace:

/people/siegfried.boes/blog/2007/09/05/the-sql-trace-st05-150-quick-and-easy

with small selection and large selection. You can compare the Summary by SQL statements, so problems will appear in both cases.

The table connected to the SELECTION-SCREEN will return different amounts of data, these you should write down.

Then run for both example

SE30

/people/siegfried.boes/blog/2007/11/13/the-abap-runtime-trace-se30--quick-and-easy

Assume that the amounts of data are 10 and 100 values, then your program should need not more than N*logN nearly 20 times longer for the larger example.

This should hold for the total time, but also for all individual lines in the SE30.

The program

Z_SE30_COMPARE

/people/siegfried.boes/blog/2008/01/15/a-tool-to-compare-runtime-measurements-zse30compare

compares 2 SE30 traces.

And

Nonlinearity Check

/people/siegfried.boes/blog/2008/01/24/nonlinearity-check-using-the-zse30compare

explains how you find programming bugs.

Siegfried

[Former Member]

HI,

goto ST05 and there identify EXPENSIVE SQL statements and use field sequence instead of select * and use key fields in where condition and remove the unnessarry loops from ur program.

again run runtime analysis .

regards,

sravan.

[Former Member]

Hi,

I think there are 2 possibilities for the DB time increasing:

1. The volume of data being fetched is really high. -- In this case you might want to check the volume.

2. The query may be fine but it might be called within a loop and therefore the number of DB hits will go up.

I see that you have taken a trace from se30 which is a graphical representation of the performance. There is a button on the toll bar by clicking which you can get the details. Sort on NET field and atleast this will point to the program that is taking maximum time. You can start your analysis from here.

Regards,

Saurabh

[Former Member]

Hello rohit,

I would suggest you to go for SQL trace to analyse that instead of run time analysis

Regards,

Bhumika

[rohit_kaikala]

got the answer