2013 Oct 18 10:07 AM
Hello guys.
I have a problem to optimize my code so the program will execute faster. I am working on this program and it is a little bit taugh and the best way to finish it was that I had to Loop time to time and use Select to take data from the database.
My program has 5 Selects and 4 loops.How can I do to optimize the code and execute faster ?
Hello guys.
I have a problem to optimize my code so the program will execute faster. I am working on this program and it is a little bit taugh and the best way to finish it was that I had to Loop time to time and use Select to take data from the database.
My program has 5 Selects and 4 loops.How can I do to optimize the code and execute faster ?
2013 Oct 18 10:14 AM
Hi Taly,
Try to use FOR ALL ENTRIES if you have any relation from one table to another. Not good advice
If you are using nested loops try to use PARALLEL PROCESSING BY USING EXIT KEY WORD INSIDE LOOP key word.
IF you are using READ STATEMENT with BINARY SEARCH before doing this SORT the internal table.
Regards,
Rajesh.
Message was edited by: Matthew Billingham - removed less than optimal advice.
2013 Oct 18 10:22 AM
Three Selection that I have select All the data from the Tables and put them into internal tables. Two other Selection use Where clause.
One nested Loop loops one of the Tables that I filled from the selection (that selects all data) and the Two other nested Loops, loop just maximum 10 rows.
And also I have 2 Read statements which in which I loop the Two tables left from the selections (i mean the selections that select all data from database table) and these Read Statements use With Key ....
2013 Oct 19 7:33 AM
Once again I have to intervene because the message does not seem to be getting out there. It has been shown TIME AND TIME AGAIN that:
INNER JOIN IS BETTER THAN FOR ALL ENTRIES IN MOST CASES
So, first try INNER JOIN. If you still have performance issues, then use FOR ALL ENTRIES, and only if performance does improve with it keep that code. If it doesn't switch back to INNER JOIN.
This is not up for discussion, and I will reject any post responding to this message that try to argue otherwise. If you want to understand why what I say is true, then take the time to search for the many discussions that we've had about this over the years in this space.
2013 Oct 18 10:28 AM
First of all, try to identify where the bottleneck is by running Runtime analysis (in SE38, Program->Execute->Runtime analysis).
Here you will see also a Tips&Tricks explaining best practices from a performance point of view.
Your run your report, and then if you press the evaluation button at the bottom of the screen you will have a first review and a detail. Then you can try to focus on where the problem is
2013 Oct 18 11:16 AM
I don't now how to use it? I wrote the trasnaction, and selected my program, when i go to Execute it doesn't show me the screen of yours!
2013 Oct 18 11:30 AM
2013 Oct 18 10:29 AM
Not possible to help without seeing actual code, so as a generic hint try running an ABAP trace with transactions SAT or ST12 (search for existing blogs explaining how to use them), sort the hit list descending by net processing time and focus on the top few entries in the list. Here is where most time is spent and where adjusting code makes sense.
Post those code snippets here, if you are unsure how to proceed from there.
Thomas
2013 Oct 18 10:35 AM
Hi Taly,
You may want to take a look at this document and identify the suitable rules that you can apply to improve your code's performance.
Efficient Database Programming with ABAP
http://scn.sap.com/docs/DOC-10416
Some general rules are:
- Keep the data queried as small as possible (e.g. precise query with more conditions to the index in WHERE clause)
- Minimize the round trips between Application Server and Database Server (e.g. avoid using SELECT in LOOP)
- Sort itab and use BINARY SEARCH for READ statement
You probably want to share your pseudo-code so it is easier for people to point out the possible improvement points.
Hope it helps. Cheers!
2013 Oct 18 11:17 AM
Without Sorting the Table, and using BINARY Search what are the consequences?
2013 Oct 18 11:40 AM
Well basically using READ statement without any additional keywords, system will perform a linear search till you reach the data you looking for. This will be really slow if data in your itab is huge.
With sorted data and using BINARY SEARCH, the algorithm will really improve the time taken to find the data you need.
You may want to run report RSHOWTIM --> Internal Table --> Linear Search vs. Binary Search to see the performance comparison
If internal tables are assumed to have many (>20) entries, a linear search through all entries is very time-consuming.
Try to keep the table ordered and use binary search or used a table of type SORTED TABLE.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Cheers!
2013 Oct 18 2:13 PM
You may not be able to search the correct record through read table then. I feel the issue here is very open ended. Can you be more specific about your requirements here?
Thanks,
Anupam
2013 Oct 19 7:37 AM
13 years ago, SAP introduced SORTED and HASHED tables, and yet the advice continually being given is to sort tables and use binary search.
What is the matter with you people?
If you are on release 4.6c or higher, there are very few scenarios requiring the use of standard tables that you must then sort and use binary search to read. If you want fast access, use HASHED tables. They're not difficult.
2013 Oct 18 10:48 AM
2013 Oct 18 12:54 PM
Hi,
I suppose all the select statement that you have written are mandatory.Based on that I would like to suggest some optimization ways.
1)Firstly, whenever you are using the select statement specify all the key fields in the select query of that table.This is very much recommended while using for all entries also.
2)In loops try to use where clause and No loop inside loop.
3)sort internal table before reading it.
4)Read table in binary search mode, this helps helps reading internal table faster.
5)Use sy-subrc after every query.That is a good practice.
Hope this helps. But it will be better if you can paste your code here.
Regards
2013 Oct 18 2:32 PM
Hi,
For better performance of code follow the follow the below points.
1) Avoid select * from table and use the particular fields if possible.
2) Use where cluse in Select statements.
3) Use Binary search when fetch data from ITAB and before use sort the ITAB.
4) Use perform statements for better clarity of code.
4) Use sy-subrc = 0
5) Use for all entries when work on ITAB to avoid data duplicate Less than the best advice
Message was edited by: Matthew Billingham - crossed out point 5, see note above in red.
2013 Oct 18 3:21 PM
Now that the truisms are pouring in, wouldn't it better you do as suggested and either post your code or run a performance trace?
Thomas
2013 Oct 19 7:39 AM
Quite. Proper information has not been posted on this thread, I have removed the question status and marked it as a discussion, thereby removing all points earned.
2013 Oct 19 8:35 AM
This wiki article Learn For All Entries - Things to consider before use says "Always use for all entries rather than join" in the end. Perhaps you would like to take action on that.
2013 Oct 19 11:22 AM
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |