Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

how to check the performance of a report

Former Member
0 Kudos

plz tell me all the ways to check the performance of a report

if u send me the step wise then it will be really helpful to me

awaiting for u r reply

8 REPLIES 8

Former Member
0 Kudos

Hi,

Things to remember to optimize performance

1) Do extended Program check ( se38->program->check->extended program check )

2) Use binary search.

3) Use abap runtime analysis

4) Sql Trace ST05

5) Avoid nested loops ........ use loop ...then binary search a table then loop from sy-tabix till key mismatch.

6) Minimize database access time

Please go through the link for performance Analysis.

Performance tuning for Data Selection Statement

http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm

2. Run Time Analyser

http://help.sap.com/saphelp_47x200/helpdata/en/c6/617cafe68c11d2b2ab080009b43351/content.htm

6. Coverage Analyser

http://help.sap.com/saphelp_47x200/helpdata/en/c7/af9a79061a11d4b3d4080009b43351/content.htm

7. Runtime Monitor

http://help.sap.com/saphelp_47x200/helpdata/en/b5/fa121cc15911d5993d00508b6b8b11/content.htm

8. Memory Inspector

http://help.sap.com/saphelp_47x200/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/content.htm

Message was edited by: Manoj Gupta

Message was edited by: Manoj Gupta

Former Member
0 Kudos

Hi,

Chk out this link:

Hope it helps you.

Regards,

Anjali

Former Member
0 Kudos

Hi,

Try the following suggestions...

1. Minimize the database hits. E.g. if u r executing any SELECT statement inside LOOP...ENDLOOP, try to remove that.

2. Check if u can use JOINS rather than executing 2 or more separate SELECT statements.

3. If u r performing some operations on internal tables by looking for a particular value in LOOP AT itab...ENDLOOP, try to use LOOP AT itab WHERE condition...ENDLOOP. Or if u r removing records in LOOP...ENDLOOP, try to exclude those records in SELECT statement only.

4. U may also use ABAP Runtime Analysis (SE30), and SQL Trace(ST05) to analyse the performance of yr code.

Cheers

VJ

Former Member
0 Kudos

Hi Ravi,

The best tool available for static checking is SCI.

sap code inspector.

tcode for this tool is sci.

with the help of this you can directly know the performance of your report.this is helpful for checking the performance not only for single report but more than one report or fm etc.

Also directly for a report you can check just click the program button then check then select the code inspector option.

It shows the output in the form of information,warning messages which helps a lot.

Please reward for the same.

0 Kudos

hi,

there are so many tools with which we can check for the performance of a Program,

1. Do EPC( Error Program Check path : ( se38->program->check->extended program check )

2. <b>RTA</b> ( Run Time Analyzer Path: SE38->UTILITIES->MOREUTILITIES->RUN TIME ANALYSIS )

3. SQL Trace ( T- Code<b> STO5</b> )

4. Code Inspector(( se38->program->check->code Inspector)

try using either one of them to know the same

Regards,

Santosh

LucianoBentiveg
Active Contributor
0 Kudos

We use a third party program:

www.abovesoft.com

Former Member
0 Kudos

I. Non Database Performance

Dead Code (Program -> Check -> Extended Prog. Check) - unused subroutines appear as warnings under PERFORM/FORM interfaces. - unused variables appear as warnings under Field attributes. Transaction code is SLIN. This will also catch literals (section III below).

When possible use MOVE instead of MOVE-CORRESPONDING (move bseg to *bseg or move t_prps[] to t_prps2[] if you want to copy entire table or t_prps to t_prps2 if you only want to copy header line.)

Code executed more than once should be placed in a form routine.

SORT and READ TABLE t_tab WITH KEY ... BINARY SEARCH when possible especially against non-buffered table (Data Dictionary -> Technical Info)

SORT tables BY fields

Avoid unnecessary moves to table header areas.

Subroutine parameters should be typed for efficiency and to help prevent coding and runtime errors.

II. Database Performanc

Avoid ORDER BY unless there is index on the columns - sort internal table instead

SELECT SINGLE when possible

SELECT fields FROM database table INTO TABLE t_tab (an internal table) - Lengthy discussion.

Views (inner join) are a fast way to access information from multiple tables. Be aware that the result set only includes rows that appear in both tables.

Use subqueries when possible.

"FOR ALL ENTRIES IN..." (outer join) are very fast but keep in the mind the special features and 3 pitfalls of using it.

(a) Duplicates are removed from the answer set as if you had specified "SELECT DISTINCT"... So unless you intend for duplicates to be deleted include the unique key of the detail line items in your select statement. In the data dictionary (SE11) the fields belonging to the unique key are marked with an "X" in the key column.

(b) If the "one" table (the table that appears in the clause FOR ALL ENTRIES IN) is empty, all rows in the "many" table (the table that appears in the SELECT INTO clause ) are selected. Therefore make sure you check that the "one" table has rows before issuing a select with the "FOR ALL ENTRIES IN..." clause.

(c) If the 'one' table (the table that appears in the clause FOR ALL ENTRIES IN) is very large there is performance degradation Steven Buttiglieri created sample code to illustrate this.

Where clause should be in order of index See example.

This is important when there are multiple indexes for a table and you want to make sure a specific index is used. This will change when we convert from a "rules based" Oracle optimizer to a "cost based" Oracle optimizer. You should be aware of a bug in Oracle, lovingly referred to as the "3rd Column Blues". Click here for more information on indexes.

Where clause should contain key fields in an appropriate db index or buffered tables. As long as we are using the Oracle Cost Based Optimizer, be aware fo the "Third Column Blues", an Oracle bug.

Avoid nested SELECTs (SELECT...ENDSELECT within another SELECT...ENDSELECT). Load data in internal tables instead. See item 3 above.

Use SQL statistical functions when possible (max, sum, ...)

Delete all rows from a table. A where clause is mandatory. Specifying the client is the most efficient way.

Put Check statements into where clause - caveat: Make sure that the index is still being used after you add the additional selection criteria. If the select statement goes from using an index to doing a db scan (reading each row in the database without going through an index) get it out of the where clause and go back to using "Check"!

III. Literals

Codes ('MD') should use contants (c_medical)

Longer text should use text elements. Sample code is a good example because it uses the text element in conjunction with the hard coded text. This documents the text element and provides for the possibility of multi-language support.

IV. Miscellaneous

Use CASE statement instead of IF...ELSEIF when possible (It is only possible in equality tests)

Nested If - encounter most likely to fail first (specific to general)

And - encounter most likely to fail first (specific to general)

OR's - encounter most likely to succeed first (general to specific)

Variables should use Like when possible

Subroutine usage - don't place decision to execute in the subroutine

If not ( t_prps[] is initial ) (instead of describe table t_prps lines sy-tfill, if sy-tfill > 0...)

New document types confirmed with the configuration team via MIT-ABAP mail list prior to coding a report to access the data.

Dates need to be properly formatted using the user's default settings. For the explanation of the BDC example check out the developer's standards.

regards,

suryaprakash.

andreas_mann3
Active Contributor
0 Kudos

hi,

or look here:

Andreas