7 - Part 1 - Writing and Tuning ABAP Programs For Best Performance

SAP Development Community of Experts
The Development Soapbox
The Elimination of Waste:

Writing and Tuning ABAP Programs for
Best Performance
2008.06.24
Ian Maxwell
(Ian.Maxwell@Accenture.com)
1
Writing and Tuning ABAP Programs for Best The Development Soapbox
Performance
In the years that Ive spent working with
SAP development a lot of my time has
been spent looking at areas of
performance tuning
Unfortunately performance
considerations have often been treated
as an after thought
This is not an exhaustive presentation it
covers a few areas that should be
considered when looking at performance
2
Writing and Tuning ABAP Programs for Best The Development Soapbox
Performance
When it comes to performance some of
the common things we hear from
projects are:
We are going live next week and our
nightly batch schedule takes over 40 hours
to run!
Creating a single sales order takes 5
minutes
The program sits there and doesnt seen
to do anything for hours
HELP!!!!!!
3
Performance Optimization The Development Soapbox
Performance optimization is about the

elimination of waste
Its important to recognize that every
executable statement in your program
has a certain cost associated with it and
that the context which the statement is
in can effect its impact on the overall
runtime
Understand:
The cost of each statement
The context that the statement is used in
4
Stepwise Isolation and Refinement The Development Soapbox
In order to optimize ABAP programs there are several

techniques that can be used:
Analysis of the code for common patterns
Running and tracing of the programs to identify bottlenecks
(SE38, SE30, ST05, SM50)
Analysis of specific SQL statements (ST05, SE11)
Often performance tuning can be thought of as pealing
an onion, where you need to remove one bottleneck in
order to identify further ones. It is a process of
stepwise isolation and refinement.
ex. Create a new ex. Reduce nested

Secondary Index loops
Isolation & Refinement 5

Bottlenecks The Development Soapbox
Bottlenecks are not always obvious because they can be far

down in either custom or standard code
Especially true for
User-exits
Pricing routines
Common code
SE30 can be useful for identifying bottlenecks
Bottleneck Bottleneck
6
ABAP Performance The Development Soapbox
Performance of an ABAP program is

made up of several dimensions and
for optimization all of these need to
be considered
Application + Database + System =

Processing Processing Processing
Overall ABAP
Performance
Excessive
Nested No Index Poor Commit Network
Data Dispatcher
Loops Support Logic Latency
Manipulation
Sequential Poorly
Redundant Unnecessary Program
Scanning Of Structured
Operations Selects Generation
Data Selects
Expensive Excessive Selects

Large Data
Operations Memory Within
Transfer
Within Loops Usage Loops
7
Design For Performance The Development Soapbox
Organize your programs for optimal

performance
Think through the design of the program
before starting coding
Think about the processing time
required for every piece of code and
eliminate waste
As a rule of thumb, the fewer times that
you access data the better performing
your program will be. This includes both
data in the database and in memory
8
The Performance Tuners Tool Box The Development Soapbox
In tuning ABAP programs there is a tool-box of standard

transactions available that can be used for both
identification of performance issues and analysis of root
causes, some of these transactions are:
SE30 ABAP Runtime Analysis

Can be used to identify bottlenecks with traces on running ABAP programs
ST05 Performance Analysis
Can be used to trace the database activity for running ABAP programs and to understand how
the database optimizer handles various SQL statements
SM37 Background Job Management
Can be used to identify which programs are running for long periods of time
SM66 Work Process Overview
Can be used to identify programs that are running long or are frequently Stuck on a
database operations. It also provides process resource utilization
SM04 User Overview
Can be used to identify what transactions are being executed and their memory consumption
ST04 Database Performance Analysis
Can be used to identify expensive SQL statements that are executed frequently in the system
SE38 ABAP Editor
Can be used to review the code for root causes to performance problems
ST22 System Short Dumps
Can be used to identify programs that are causing reoccurring problems in the system
STAD System Workload Analysis
Provides statistics and metrics on the run-time history of programs
9
The Performance Tuners Tool Box - The Development Soapbox

SE30 (Being replaced by SAT)
SE30 is the ABAP Runtime trace transaction
Can set a variant to control what will be
traced
By sorting results on the Net runtime results
you can identify what parts of the program
are taking the most amount of time
Can trace in several modes:
Foreground
Background
Scheduled
Note If running on a multi-processor server
it is important to set the Measurement
Accuracy to Low, otherwise you will can
strange (sometimes negative) runtimes
10

One of the features that SE30 provides is a graph showing
the % of the processing time used by:
ABAP
Database
System
Often developers will include a screen shot of this graph as part

of their unit test plans. The fact is though, this really means
nothing unless it is put in context.
One question that I always get is What should the percentages
be if the program is performing well?. There is no straight
answer to this question because once again it requires
understanding the context.
Where this graph is actually useful is in understanding what area
to target if the program is not running within the required 11
runtime.

The runtime trace provides both Gross and Net runtime results.
Net results are useful for identifying individual operations that are
possible performance issues while the Gross results can identify
sections of the program.
The runtime trace also shows the number of times that an operation
is executed.
Gross = 15% Gross = 10%

Net = 5% Net = 10%
Note Sorting the results in
Gross = 100%
Net = 5% Gross = 5% descending net runtime order
Net = 5%
will usually reveal a number of
Gross = 45%
Net = 45% operations that require
Gross = 75%
Net = 25%
examination for performance
issues
Gross = 5%
Net = 5%
12

ST05
ST05 is primarily used as an SQL trace but also
can be used for tracing RFCs and other features
of the application server
Allows you to view the SQL statements as they
appear to the database
By doing an explain on a SQL statement you can
understand the access path that the Database
uses
Indexes
Order of operations
For an Oracle database, the following guide can
be useful when trying to understand SQL
Explains:
https://tsamr.accenture.com/sites/Architectur
e_Infrastructure_Home/Repository/Oracle%20Dat
abase%20Performance%20Tuning%20Guide%20and% 13
Reference.pdf
The Impact of Data on Performance The Development Soapbox
The majority of performance issues in ABAP

programs are related to data
Understand your data, both in the database
and in program memory!
Volume and Growth of data
Relationships between pieces of data
Organization of data
Access to data
A program that may perform within
expectations at one point in time may slow
down over time due to an increase in size of
the database or the size of the data being
processed
14
The Impact of Data on Performance The Development Soapbox

Linear vs. Exponential
The progressive slowing down of programs can fall
into two categories:
Linear
Exponential
Both types of increase to runtime can be damaging

to performance and need to be examined
Exponential increases become damaging to system
performance very quickly and run the risk of
brining it to a stand-still
The decrease in performance can be due to either
ABAP Processing or Database Processing
15
Internal Table Access
16
Internal Table Access The Development Soapbox
Its important to understand how internal

tables are being utilized, they can have as
much as an effect on a programs runtime
(Or more) as database access
Internal tables are essentially data arrays
Performance of an array access is
dependant on the following:
Number of records
Number of lookups
Lookup algorithm
Sort overhead
17

Table Types
There are various types of internal tables available in ABAP
Standard
Have no specific sort order
Can be sorted using a Sort statement
Operations such as Read and Loop are unaware of any sort
operations that have been done
A Binary Search operation is possible if the table is sorted by:
A Sort operation
Maintained as a sorted list based on other program logic
Sorted
Has a specific sort order
A Binary Search operation is possible
Hash
Has no specific sort order
Reads use a hashing algorithm
Loop operations are based on the order that records were added
Note - In NetWeaver 7.1 there is additional support for
internal tables in the form of secondary indexes
18
Internal Table Access - The Development Soapbox

Search Algorithms
Standard Table: Not Sorted

1 4 17 5 16 18 2 53 30 67 9 65 40 3 19 60 49 64 15 42 41
65 Sequential Scan - Search 12 records
Average search time = n / 2 = 21/2 = 10.5
Standard Table: Sorted

1 2 7 8 9 15 17 20 21 22 23 24 34 37 48 49 50 53 55 56 68
34 Binary Search - Search 3 records
Average search time = log2n = log221 = 4.4

Sequential Scan - Search 15
34 records
Average search time = n / 2 = 21/2 = 10.5
Hash Table
88 4 90 5 27 18 2 53 30 67 13 65 40 3 19 85 49 64 15 42 79
64 Hash Search - Search 1 record
Average search time = 1
19

LoopWhere
Loop at i_FooBar
=
Loop at i_FooBar
INTO wa_FooBar.
INTO wa_FooBar
WHERE Blah = l_Blah.
If wa_FooBar = l_Blah.
***** Do Stuff ***
***** Do Stuff ***
EndIf
EndLoop.
EndLoop.
It is a common misconception that the LoopWhere syntax on a standard internal table will
help the performance of a loop. It actually will still do a sequential scan of the data so the
above two code segments are equivalent from a performance perspective. Because the loop
statement has no knowledge of the sort order of a standard internal table it must look at every
record even if it has been previously sorted.
If the loop is only executed once then a LoopWhere syntax is not usually an issue but if the
loop is nested then it is executed multiple times and there can be a high amount of waste.
20

LoopWhere
A common performance pattern that can be implemented is Binary Search + Loop From
Index + Exit as shown here:
Read table i_FooBar
1) A binary search is executed to find the first Transporting no fields
record that matches the criteria. If there are With key Blah = l_Blah
multiple records that match the criteria then sy- Binary search.
tabix will always be the index of the first one. l_Tabix = sy-Tabix.
2) The loop statement starts its iterations at the Loop at i_FooBar

INTO wa_FooBar
index of the first matching record.
From l_Tabix.
3) If the record is not a record that matches the If wa_FooBar-Blah <> l_Blah.
Exit.
criteria then all matching records have been Endif.
processed and you can exit the loop.
***** Do Stuff ***
Note, for the code to work it is important that the table
is sorted appropriately by the field Blah. EndLoop.
If this is a nested loop then it is important to

remember that the sort of the table needs to be done
outside of the outer loop, otherwise this will negate
the performance improvements!
21

LoopWhere
Table i_FooBar sorted by field Blah

Records where
Blah = l_Blah
Savings: Records proceeding the Savings: Records trailing

matching records are ignored the matching records are
Start of loop Exit from loop ignored
from index
Reduce waste by not processing records that you dont need to!
22

Case Study - LoopWhere
Overview
Program ZPMMI1120_CHESS_DEMANDFEED_CLT was observed running as a
background job in the QA environment for a long duration with minimal DB activity
so a trace was done to understand if there is inefficient ABAP looping or reading
logic being performed.
Observations
The trace was done for ~4.6 minutes with 87% of the time being taken on ABAP
logic. Note, this trace is only of the period of time that was observed as the
program was running and does not include other areas of the program that could
potentially be tuned.
23

Case Study - LoopWhere
Runtime analysis sorted in descending order by the Net Runtime:
IT_49 75.6%
LOOP AT i_mdsb INTO wa_mdsb1
WHERE matnr EQ wa_mdsb-matnr
AND bdter GT wa_mdsb-bdter.
This loop on i_mdsb is nested and will always do an exhaustive sequential scan on the
internal table.
Recommendation: The internal table is already sorted by Matnr and Bdter. I suggest a
more effective access pattern of Binary Search + Loop From Index + Exit instead of
using a loop where.
24

Why Use a Binary Search?
The following chart shows three different scenarios:
Lookup Description Average Runtime
Algorithm
Search Records are accessed as a sequential access
Sequential Average runtime complexity for a search is n/2 = n/2 * s
There is no sort required
Sort + Search Records are accessed using a binary search = nlog2n + ( log2n *
Binary Average runtime complexity for a search is log2n s)
A sort is required before any searches can be performed
A sort runtime complexity is nlog2n
Search Binary Records are accessed using a binary search = log2n * s

(No sort) Average runtime complexity for a search is log2n
A sort is not required because records are being inserted in the
correct order (i.e. it is a growing array) or it has already been
sorted as part of another process
n = number of records
s = number of searches
25

Why Use a Binary Search?
There are a couple of
Results - Runtime Operations for 100 searches conclusions that can be made
from this:
If there is no sort required binary
search will give better results on
even a small number of records
If there is a sort required then
the sort should only be done
once up front in order to support
all of the reads.
If you are reading the array at
Results - Runtime Operations for 15 searches least ~15 times through the
duration of the program then the
binary search will provide better
performance then the sequential
scan regardless of the size of the
number of records
Even if there end up being less
then 15 reads the binary search
wont cause any major
26
performance issues

Parallel Cursor Pattern
A common performance issue in ABAP programs is
related to looping on internal tables.
The result of nested loops can cause significant decrease
in program run-time.
There are a number of different techniques to handle
nested loops, one of which is the use of a design pattern
called Parallel Cursor.
The parallel cursor pattern can be used in cases where :
There are multiple tables being looped through
The full key of the table in the outside loop is the first part of the
key for the inside loop
The tables are both sorted according to their keys
The parallel cursor pattern is also useful when
attempting to compare the contents of internal tables.
By utilizing this technique you can identify :
Which records are common to both tables
Which records are in the first table only
Which records are in the second table only
27

An example of the Parallel Cursor Pattern:
sort i_tab1 by K1 ascending.
sort i_tab2 by K1 ascending
K2 ascending.
l_pos1 = 0.
clear wa_tab1.
loop at i_tab1 into wa_tab1.
clear l_found.
clear wa_tab2.
loop at i_tab2 into wa_tab2
from l_pos1.
l_pos1 = sy-tabix.
if wa_tab2-K1 < wa_tab1-K1.
*** This represents a record in tab2 that does not
*** contain a corresponding record in tab 1
Insert appropriate
elseif wa_tab2-K1 > wa_tab1-K1.
logic to be executed *** All records for the current key have been processed
when matches are *** and there fore the inner loop should be exited
either found or not exit.
found else.
*** A record in tab2 that corresponds to the record
*** in tab1 has been found.
l_found = 'X'.
endif.
clear wa_tab2.
endloop.
if l_found is initial.
*** No records were found in tab2 that correspond
*** to the record in tab1
endif.
clear wa_tab1.
endloop. 28

The attached document

contains additional
information regarding the
Parallel Cursor
Micros oft Word

Document
29
Database Access
30
Database Access The Development Soapbox
Database access is a key part of performance tuning and requires a good understanding of how the underlying database handles queries.
Every database access has a cost associated with it.
Note This presentation will focus on the use of an Oracle database, although the main concepts can be used when looking at performance on
a variety database systems for SAP
Co
SQL
Database
st
Data
?
31
Some of the considerations that should be

looked at when examining the performance
of a SQL statements in ABAP programs:
Number of records in the table
Number of records expected to be returned
Uniqueness of requests
Fields in the where clause and how they are
related to:
Leading fields of the primary key
Leading fields of secondary indexes
Statistics for Oracles Cost Based Optimizer
(CBO)
32
Database Access - The Development Soapbox

Oracle Cost Based Optimizer
CBO
Data Statistics
Gather Statistics
Prepared SQL Statement CBO

Tables(s) Determine Index
Fields(s)
Where Condition(s)
Hint(s)
Oracle RDBMS
SAP Open SQL Layer SAP NetWeaver
ABAP Program
SQL Statement
33

Oracles CBO is based on statistics and
determines the most appropriate index to
use
Although the CBO can identify an index
based on statistics it sometimes can have
results that are not optimal
Hints can be added to SQL statements to
influence the CBO. You should always be
careful when using hints because:
Hints are specific to the database implemented
(ex. Oracle)
As data grows and changes in the table you need
to be careful that the hint will always be relevant
34

Out of date statistics can cause an
incorrect access method
For example if there is an index on a field
FooBar~CreateDate and statistics are out
of date then the optimizer might not
realize that this index actually contains a
significant number of unique values
If a non-ideal index is being used then
have the DBA execute a statistics update.
Often this will solve the problem
Statistics are especially an issue after
conversion because a table can go from
zero records to thousands or millions
35

Selectivity
Usually non-optimal results from the
CBO are based on issues with the
selectivity of a field
Selectivity is the fraction of rows in a
table that the SQL statements
predicate chooses. The optimizer uses
the selectivity of a predicate to estimate
the cost of a particular access method
and to determine the optimal join order
and join method. Oracle Tuning guide
36

Selectivity
Low selectivity fields are an issue for the CBO
A common example:
Table FooBar contains 1,000,000 records
There is an index on field FooBar~Status which is a single
character field that is used as a status indicator and has the
following values
0 (Not processed) 1,000 records
1 (Processed) 999,000 records
There is a batch program to pick up records that are in
status 0 (Not processed), does some work and then marks
the record with status 1 (Processed). The status field
prevents records from being picked up if they have already
been processed
This example seems like it shouldnt have any
performance issues because the index on the status
field should allow the batch program to quickly
access the not yet processed records
Or will it?
37

Selectivity
Heres the problem associated with this
example
The CBO calculates a selectivity of the index
based on the number of unique values and
the total number of records:
1,000,000 records
2 unique values
Therefore each value represents 500,000 records
(According to the CBO)
The CBO doesnt recognize that the Not
Processed status represents only a small
portion of the total records (Low Selectivity)
38

Selectivity
Actual Data The CBOs Statistics Based
Distribution View of the Data Distribution
999,000 500,000
Records Records
99.9%
500,000
Records
1,000
Records 0.1%
Due to the low selectivity the index will be ignored and the
optimizer will choose another access method.
39

Index Selection (Using Leading Fields)
Order of fields in an index can effect the access method
Multi-Field Index:
Order Customer Create
Type Number Date
Good Candidate: All fields in
Select.
the index are utilized
Where Order_Type = A
And Customer_Number = 12345
And Create_Date = 20080610
Good Candidate*: The

leading fields of the index
are utilized Select.
Where Order_Type = A
* As long as the utilized And Customer Number = 12345
fields are considered
selective enough
Poor Candidate*: Even though

Create Date is part of the where Select.
clause the index cant be used Where Order_Type = A
efficiently because the Customer And Create_Date = 20080610
Number isnt included
* Note that if Customer number
is a low selectivity field then the
optimizer may still decide to use
the index 40

Index usage over time
Consider the indexes being utilized and understand
if they will continue to be optimal as time
progresses. For example:
An index on a table of sales order lines for the following
fields:
Line item category
Material number
A where clause on a SQL statement is using the following
fields:
Line item category
Material number
Delivery date
Although this SQL may initially be fast it may slow down
as time progresses because delivery date is not part of
the index
Everything that isnt part of the index will be used as a filter
after applying the index
41

Redundant DB Access
The pigeonhole principle, states that, given two natural numbers n and m with n >
m, if n items are put into m pigeonholes, then at least one pigeonhole must contain
more than one item.
9 Pigeonholes and 10 Pigeons:

At least 1 Pigeonhole must contain at least 2 Pigeons
What does this have to do with accessing a database?

If a database table contains 100 records and there are 1,000 queries performed
against it then there is at least 1 record that is queried multiple times.
Specifically there are at least 900 queries that are redundant.
42

Redundant DB Access
Accesses to the database can be thought of as a mathematical
function:
y = f(x)
If y is a function of x then f(x) will always result in the same value for
y when evaluated for the same value of x repeated times.
Similarly, if a SQL statement is retrieving records based on values in a

where clause then the resulting records will be the same if the same
values are used in the where clause for multiple calls.
Database queries have a performance cost associated with them and if

you are retrieving the same record multiple times then this should be
considered as waste.
43

Redundant DB Access
A common spot where redundant DB
accesses are seen is in user exits
An example of this would be a user exit in
sales order processing that is executed for
each line item. The user exit is going to get
called multiple times, sometimes even
multiple times for the same line item
If the user exit was implemented to do a
SQL lookup up of material master data on
the MARA table
Most likely the same records are going to be
requested from the MARA table multiple
times
44

Redundant DB Access
Techniques to use to eliminate redundant
DB accesses:
Using static variables to cache values
Static variables have local scope and global lifetime
Using static classes to cache values
Using shared memory access to keep
commonly used data in memory across
multiple processes (ex. a product catalog)
Hint: A program that is well organized in a
modular style will be easier to apply these
techniques to
45

Redundant DB Access
Main Program User-Exit A
. . Common Select
. . Mara Routine
. . .
Call User-Exit A Call Select MARA . Cached MARA
. . . values
. .
. .
User-Exit B
. Select From MARA
. Mara
Call User-Exit B .
.Call Select MARA
.
.
.
By centralizing data access, the cache can be used across various parts of
the program.
46

Redundant DB Access
Common routine for accessing Mara:
Using
l_Vbeln type Vbak-Vbeln
l_Matnr type Mara-Matnr
Changing
l_Mara type Mara
Types: Clear l_Mara.
Begin of t_Cache,
Matnr type Mara-Matnr, Read table ls_hash_Cache
2
Mara type Mara, Into l_Cache
End of t_Cache, With Table Key Matnr = l_Matnr.
t_hash_Cache type hashed If sy-subrc = 0.

table of t_Cache with unique key Matnr. l_Mara = l_Cache-Mara.
Statics: else.
ls_hash_Cache type t_Cache, Clear l_Mara
ls_Vbeln type Vbak-Vbeln. Select Single * 3
Data: From Mara
l_Cache type t_Cache Into l_Mara
Where Matnr = l_Matnr
If l_Vbeln <> ls_Vbeln.
Clear ls_Hash_Cache. 1 Clear l_Cache.
Ls_Vbeln = l_Vbeln. l_Cache-Matnr = l_Matnr 4
endif. l_Cache-Mara = l_Mara
Insert wa_ZZTOS into table ls_Hash_ZZTOS.
endif.
1 Clear the cache when a certain criteria is met. In this example the Sales Order Number is used
2 Check the cache to see if the record has already been read (Note, the lookup uses a hash for fast access)
3 Because the value wasnt in the cache, lookup the record in the database
4 Add the record to the cache

47
Some additional things to look out for

with database performance:
Selects inside loops
By doing an array operation (For All Entries)
you can reduce the overhead of the database
calls
Selecting more data then you need
Joins that result in inefficient access paths
SelectEndSelect
Should not be used except in cases where you
are using Up To X Rows
48
Divide and Conquer
49
Divide and Conquer The Development Soapbox
A divide and conquer approach involves the multi-

threading of a program such that there can be
multiple processes working together to complete the
job in less time
The optimum number of processes to use is based on:
The type of processing being done
The system resources available
Batch Window
1 Process: 10 Hours
2 Processes: 5 Hours
5 Hours
4 Processes: 2.5 Hours
2.5 Hours
2.5 Hours
2.5 Hours
Note This example assumes no diminishing returns (Covered in later slides)
50
When is it time to look at a divide

and conquer approach?
A program is overall running fast but the
volume is high. For example a program
takes only 1 second per record to
process but there are 100,000 records to
process. Single threaded this program
will take over 27 hours to run.
A program is running slow and there is
no way to effectively speed it up on a
single thread
51
Divide and Conquer - The Development Soapbox

How many threads?
It is important to realize that due to
finite system resources there will be
a point where adding additional
processes will result in diminishing
returns Diminishing Returns
There is a point where 12.00

adding additional 10.00
Runtime (Hours)
threads doesnt result 8.00 Without Diminishing

Returns
in a further decrease in 6.00
With Diminishing
runtime. There is also 4.00 Returns
a point where 2.00
additional threads may 0.00
result in an increase in
runtime due to Number of Threads
contention for
Note: The following is for example purposes only, results will vary depending on the specifics of the job
resources and the system
52

Load Balancing
There are various approaches to parallel processing
which fall into two main categories:
Static Load Balancing Dynamic Load Balancing
2 4 9 2 4 9
6 6
1 1
3 7 3 7
5 8 5 8
Enqueue Object and/or Driver Process

Process 2
Process 3
Process 1
Process 2
Process 3
Process 1
1 4 8 2 5 7 3 6 9 1 5 9 8 4 6 2 3 7
Records are divided up based on a predefined All processes continue until there are no records
criteria or a preprocessing program remaining to be processed. All processes complete
processing at approximately the same time
If some records take longer to process then others
then some processes will finish later then others Processes can be added or removed at runtime
53

Load Balancing
Examples of static load balancing implementations:
Logical splitting via variants Preprocessor for splitting into queues
Execute on Execute on
Customer group Data Customer group Data
Z01 Z02 Execute on
Preprocessor a queue
Creates Queues
Queues
Examples of dynamic load balancing implementations:
Driver/Worker model via Asynchronous RFCs Worklist pattern via Enqueue Objects
Worker Work
Data Processing List
Data Program
Driver
Enqueue Server
54
Hint: Always consider parallel processing

during the design of a program so that if
required it doesnt require a significant
redesign
Hint: The SAP ALE system is designed to
process IDocs using dynamic load
balancing. A quick way to convert an
existing program for parallel processing is
to put all of the update logic into an IDoc
function. The main program creates the
IDocs and then they are executed in parallel
55
Questions
?
56

7 - Part 1 - Writing and Tuning ABAP Programs For Best Performance

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

7 - Part 1 - Writing and Tuning ABAP Programs For Best Performance

Hochgeladen von

Copyright:

Verfügbare Formate

SAP Development Community of Experts

The Development Soapbox

The Elimination of Waste:

Performance Optimization The Development Soapbox

Performance optimization is about the

Stepwise Isolation and Refinement The Development Soapbox

In order to optimize ABAP programs there are several

ex. Create a new ex. Reduce nested

Isolation & Refinement 5

Bottlenecks The Development Soapbox

Bottlenecks are not always obvious because they can be far

ABAP Performance The Development Soapbox

Performance of an ABAP program is

Application + Database + System =

Expensive Excessive Selects

Design For Performance The Development Soapbox

Organize your programs for optimal

The Performance Tuners Tool Box The Development Soapbox

In tuning ABAP programs there is a tool-box of standard

SE30 ABAP Runtime Analysis

The Performance Tuners Tool Box - The Development Soapbox

The Performance Tuners Tool Box - The Development Soapbox

Often developers will include a screen shot of this graph as part

The Performance Tuners Tool Box - The Development Soapbox

Gross = 15% Gross = 10%

The Performance Tuners Tool Box - The Development Soapbox

The Impact of Data on Performance The Development Soapbox

The majority of performance issues in ABAP

The Impact of Data on Performance The Development Soapbox

Both types of increase to runtime can be damaging

The Development Soapbox

Internal Table Access

Internal Table Access The Development Soapbox

Its important to understand how internal

Internal Table Access The Development Soapbox

Internal Table Access - The Development Soapbox

Standard Table: Not Sorted

Standard Table: Sorted

Average search time = log2n = log221 = 4.4

Internal Table Access The Development Soapbox

Internal Table Access The Development Soapbox

2) The loop statement starts its iterations at the Loop at i_FooBar

If this is a nested loop then it is important to

Internal Table Access The Development Soapbox

Table i_FooBar sorted by field Blah

Savings: Records proceeding the Savings: Records trailing

Internal Table Access - The Development Soapbox

Internal Table Access - The Development Soapbox

Internal Table Access - The Development Soapbox

Search Binary Records are accessed using a binary search = log2n * s

Internal Table Access - The Development Soapbox

Internal Table Access - The Development Soapbox

Internal Table Access - The Development Soapbox

Internal Table Access - The Development Soapbox

The attached document

Micros oft Word

The Development Soapbox

Database Access The Development Soapbox

Every database access has a cost associated with it.

Database Access The Development Soapbox

Some of the considerations that should be

Database Access - The Development Soapbox

Prepared SQL Statement CBO