0% found this document useful (0 votes)
121 views46 pages

AB1014 - Performance Tuning - v2.0

This document provides guidance on performance tuning ABAP code. It begins with an introduction that describes the purpose, uses, and challenges of performance tuning. It then outlines various techniques for performance tuning, including optimizing selection criteria, select statements, internal tables, typing, control statements, field conversion, and using ABAP objects. It also describes tools for performance analysis like runtime analysis, SQL trace, extended program check, and code inspector. The document demonstrates some of these tools and techniques. It concludes with exercises and additional help resources.

Uploaded by

sameer1562000
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
121 views46 pages

AB1014 - Performance Tuning - v2.0

This document provides guidance on performance tuning ABAP code. It begins with an introduction that describes the purpose, uses, and challenges of performance tuning. It then outlines various techniques for performance tuning, including optimizing selection criteria, select statements, internal tables, typing, control statements, field conversion, and using ABAP objects. It also describes tools for performance analysis like runtime analysis, SQL trace, extended program check, and code inspector. The document demonstrates some of these tools and techniques. It concludes with exercises and additional help resources.

Uploaded by

sameer1562000
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 46

AB1014 – Performance Tuning –

v2.0
Performance Tuning
1 Introduction

2 Syntax Description

3 Demonstration

4 Excercises

5 HelpMe
Performance Tuning
1 Introduction

2 Syntax Description

3 Demonstration

4 Exercises

5 HelpMe
Introduction

• Purpose
• Use
• Challenges
Introduction

Performance Tuning is nothing but


optimizing the performance of your
program through various techniques
thus increasing the productivity of the
user.
Introduction
Purpose
In this world of SAP programming, ABAP is the
universal language . Often due to the pressure of
schedules and deliveries, the main focus of making a
efficient program takes a back seat. An efficient
program is one which delivers the required output to
the user in a finite time as per the complexity of the
program, rather than hearing the comment “I put the
program to run , have my lunch and come back to
check the results”
Introduction

Use

Leaving aside the hyperbole, a performance optimized


ABAP Program has the following uses:
1. Saves the time of the end user.
2. Increases the productivity of the user.
3. In turn keeps the user and hence the management
happy.
Introduction

Challenges

Performance of a program is also often limited due to


hardware restrictions, which is out of the scope of this
tutorial.
Performance Tuning
1 Introduction

2 Syntax description

3 Demonstration

4 Exercises

5 HelpMe
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
• Select Queries
• SQL Interface
• Aggregate Functions
• For all Entries
• Select Over more than one Internal table
3. Internal tables
4. Typing
5. Control Statements (If, Case, While..)
6. Field Conversion
7. ABAP Objects
8. Tools for Performance Analysis
Selection Criteria

1. Restrict the data to the selection criteria itself,


rather than filtering it out using the ABAP
code using CHECK statement. 
2. Select with selection list.
Note: It is suggestible to make at least on field mandatory
in Selection-Screen as mandatory
fields restrict the data selection and hence increasing
the performance.
Select Statements
Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into
table clause of select statement rather than to use
Append statements.
3. When a base table has multiple indices, the where
clause should be in the order of the index, either a
primary or a secondary index.
4. For testing existence , use Select.. Up to 1 rows
statement instead of a Select-Endselect-loop with an
Exit.
5. Use Select Single if all primary key fields are
supplied in the Where condition .
Select Statements contd..
SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use
an index.
3. Using buffered tables improves the performance
considerably.
Select Statements contd…
Aggregate Functions
• If you want to find the maximum, minimum, sum and
average value or the count of a database column, use
a select list with aggregate functions instead of
computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are
MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Select Statements contd…
For All Entries
• The for all entries creates a where clause, where all
the entries in the driver table are combined with OR. If
the number of entries in the driver table is larger than
rsdb/max_blocking_factor, several similar SQL
statements are executed to limit the length of the
WHERE clause.
The plus
• Large amount of data
• Mixing processing and reading of data
• Fast internal reprocessing of data
• Fast
The Minus
• Difficult to program/understand
• Memory could be critical (use FREE or PACKAGE size)
Select Statements contd…
For All Entries

Points to be must considered FOR ALL ENTRIES


• Check that data is present in the driver table
• Sorting the driver table 
• Removing duplicates from the driver table
Select Statements contd…
Select Over more than one Internal table

1. Its better to use a views instead of nested Select


statements.
2. To read data from several logically connected tables use a
join instead of nested Select statements. Joins are
preferred only if all the primary key are available in WHERE
clause for the tables that are joined. If the primary keys are
not provided in join the Joining of tables itself takes time.
3. Instead of using nested Select loops it is often better to use
subqueries.
Internal Tables
1. Table operations should be done using explicit work
areas rather than via header lines.
2. Always try to use binary search instead of linear search.
But don’t forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since
the key specification must be evaluated at runtime.
4. A binary search using secondary index takes
considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because
LOOP ... WHERE evaluates the specified condition
internally.
6. Modifying selected components using “ MODIFY itab …
TRANSPORTING f1 f2.. “ accelerates the task of updating
a line of an internal table.
Internal Tables contd….
7. Accessing the table entries directly in a "LOOP ...
ASSIGNING ..." accelerates the task of updating a set of
lines of an internal table considerably
8. If collect semantics is required, it is always better to use to
COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task
of appending a table to another table considerably as
compared to “ LOOP-APPEND-ENDLOOP.”
10. “DELETE ADJACENT DUPLICATES“ accelerates the
task of deleting duplicate entries considerably as
compared to “ READ-LOOP-DELETE-ENDLOOP”.
11. "DELETE itab FROM ... TO ..." accelerates the task of
deleting a sequence of lines considerably as compared to
“ DO -DELETE-ENDDO”.
Internal Tables contd…

12. Copying internal tables by using “ITAB2[ ] = ITAB1[ ]” as


compared to “LOOP-APPEND-ENDLOOP”.
13. Specify the sort key as restrictively as possible to run the
program faster.
Internal Tables contd…
Hashed and Sorted tables
1. For single read access hashed tables are more
optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more
optimized as compared to hashed tables
Typing
1. Typed Parameters: Specifying the type for formal
parameters in the source code, optimizes the code
more thoroughly
2. Typed Field-Symbols: Specifying the type for
formal parameters in the source code, optimizes the
code more thoroughly
Control Statements
If, Case, While..
1. CASE statements are clearer and a little faster than
IF-constructions
2. Use of WHILE instead of a DO+EXIT-construction, is
faster to execute.
Field Conversion

1. Use fields of type I instead of P for typical integral


variables like indices.
2. Use numeric literals or named constants with a
number type instead of character strings if you are
dealing with type-I or integral type-P fields.
3. Use properly typed constants instead of literals.
4. Use number types for arithmetic. Use type-N fields
only for pure digit strings that are not intended for
calculations e.g, Telephone nos etc.
5. Don't mix types unless absolutely necessary.
6. String operations can be made faster by specifying
length of character field rather than defining as string.
ABAP Objects

1. Calling methods of global classes is faster than


calling function modules
2. Calling global methods is slower as compared to
calling local methods
Tools for Performance Analysis

• Run time analysis transaction SE30


• SQL Trace transaction ST05
• Extended Program Check (SLIN)
• Code Inspector ( SCI)
Performance Tuning
1 Introduction

2 Syntax Description

3 Demonstration

4 Exercises

5 HelpMe
Demonstration
Run time analysis transaction SE30
Demonstration
Run time analysis transaction SE30
Demonstration
Run time analysis transaction SE30
Demonstration
Run time analysis transaction SE30
Demonstration
SQL Trace – ST05
Demonstration
SQL Trace – ST05
Demonstration
Extended Program Check
Demonstration
Extended Program Check
Demonstration
Extended Program Check
Demonstration
Code Inspector - SCI
Performance Tuning
1 Introduction

2 Syntax Description

3 Demonstration

4 Exercises

5 HelpMe
Exercises

Two Test Samples attached.

Test-A Test-B
Performance Tuning
1 Introduction

2 Syntax Description

3 Demonstration

4 Exercises

5 HelpMe
HelpMe

• Tips and Tricks


• Additional Info
HelpMe
Tips and Tricks
Optimizing the load of the database
1. Using table buffering
Using buffered tables improves the performance considerably. Note that
in some cases a statement can not be used with a buffered table, so
when using these statements the buffer will be bypassed. These
statements are:
– Select DISTINCT
– ORDER BY / GROUP BY / HAVING clause
– Any WHERE clause that contains a sub query or IS NULL expression
– JOIN s
– A SELECT... FOR UPDATE
If you wan t to explicitly bypass the buffer, use the BYPASS BUFFER
addition to the SELECT clause.
HelpMe
Tips and Tricks
Optimizing the load of the database
2. Use the ABAP SORT Clause Instead of ORDER BY
• The ORDER BY clause is executed on the database server
while the ABAP SORT statement is executed on the application
server. The database server will usually be the bottleneck, so
sometimes it is better to move the sort from the database
server to the application server.
• If you are not sorting by the primary key ( E.g. using the
ORDER BY PRIMARY key statement) but are sorting by
another key, it could be better to use the ABAP SORT
statement to sort the data in an internal table. Note however
that for very large result sets it might not be a feasible solution
and you would want to let the database server sort it.
HelpMe
Tips and Tricks
Optimizing the load of the database
3. Avoid the SELECT DISTINCT Statement
• As with the ORDER BY clause it could be better to avoid using
SELECT DISTINCT, if some of the fields are not part of an index.
Instead use ABAP SORT + DELETE ADJACENT DUPLICATES on an
internal table, to delete duplicate rows.
HelpMe
Additional Info
1. Use of CONTEXT can highly optimize the code.
Context can be created using Context Builder (SE33)
Context advantages:
- no double fetch by DEMAND: 1. fetch, 2. get from buffer
- more performance (best SELECT-statement)
- better survey of code
2. Use of PARALLEL CURSOR increases the Performance to a great
extent.
3. INDEXES help to speed up selection from the database. The primary
index is always created automatically in the SAP System. It consists of
the primary key fields of the database table. If you cannot use the
primary index to determine a selection result (for example, WHERE
condition may not contain any primary index fields), you can create a
secondary index.
HelpMe
Additional Info
Optimal number of indexes for a table
You should not create more than five secondary
indexes for any one table because:
• Whenever you change table fields that occur in the
index, the index itself is also updated.
• The amount of data increases.
• The optimizer has too many chances to make
mistakes by using the 'wrong' index.
If you are using more than one index for a
database table, ensure that they do not overlap.

You might also like