Developing is done in a sequence of steps and tuning the performance of the development is one of the last steps... An ABAP can do it's trick in many ways. Getting an ABAP to do what it was specified to do is one, but getting it to do it's trick fast is another. Tuning the performance comes down to the developer applying a set of "quality assurance" rules which should always be done.
What you should do and should not do developing in ABAP where performance is concerned...
- Do Take performance seriously. There is nothing more frustrating than having to wait for results solely because the developer hasn't done his job properly
- Don't Be afraid to performance tune someone else's coding. Spaghetti coding and performance tuning don't go well together
Measure your performance improvements, find the bottle necks and check whether your performance improvement worked... Transaction SE30 - Runtime analysis should be used for your performance tune. When you start this on new systems, it will prompt for transaction SAT, the more improved version. It tells you what selections are done, which selections consume the most time and thus which improvements will have the most effect when attended to.
Performance tuning your developments can be a matter of applying some guidelines. Any developer should adhere to them as part of quality development. Do sing along !
Performance issues are often linked to database selection steps, however they needn't always be... Find out how the performance of handling internal tables can be dramatically improved... Once you are used to picking up selection results from a SELECT statement directly in to an internal table, the internal table itself could become a bottle-neck in performance.
For a single transaction analysis transaction ST12 is available, it looks tremendously promising - but I've not tried using it yet. Check out This SDN article
The performance of a report has a strong relation to the selection parameters on the report selection screen. So a common way to attack performance problems is to make e.g. a plant or date-range mandatory fields, which should then limit the selection. It also restricts the end user in the way the report can be used. So here's an alternative way to control what selections are allowed, without restricting the end user in determining how this selection is determined.
Is sitting around until it's archived. Here's what you can do with it - allow the end user (several end users) to have a look at reporting output from a batch job, which itself is too slow to be executed directly by the end user (TIME_OUT)
Spool lists are a special topic in SAP. Batch jobs keep track of output in "spool files" for which quite special treatment is required. First of all, have a play around with transaction SM37 which is about batch job scheduling. Where reporting output is available, it can be listed. Note that during your program run, the number of the spool request is in ABAP memory in variabele SY-SPONO - Print list, spool number.
When using workflow you better make sure performance does not become an issue. It's a serious system killer to have poor performance in Workflow...
Slow selections are normally less likely to happen on Workflow, because of the Business Object setup: any flow runs on a Business Object e.g. a Purchase Order and any action workflow needs to do should be quite fast because the main key fields are available. Normally. And this is how it should be.
You're working on a performance issue and you are trying to find the fastest way to process an enormous table. Wouldn't it be time for a bit of archiving ? How "big" are the tables on the system anyway ? Check out transaction DB02, which holds a lot of very relevant information on high level. In Mega / Giga / Terra or Petabytes.
When you are looking up the size a tables consumes on the system, know this: indexes on the table are likely to be around and they too are space consumers.
The system has multiple indexes, but your selections are not performing ? The system will automatically determine which index is used, which may not be what you expect at all. Here's how you can find out.
Indexes are part of the database management system and they can seriously improve the performance of your reports. They can be defined/added to a table through the data dictionary (SE11) and they require no actual changes to the report or reports you are targetting for your performance improvement. Before you add your index - read this article. Learn a bit about it. An index is a life-long task ongoing task for the system to keep up to date.
In some extreme cases, when you the system simply ignores the optimal index and you want a bit more control over the selection the database is doing for you, you may just have to hint the database server.