Proposal for a sticky thread "Performance of SAP standard"

Question

Hello,
in this form there are many questions about your programs, selects function modules but what about the SAP standard programs, they are not always the best performing things on your system. What do you think about a thread with improvements of SAP standard programs?
Ok, that should be the job of SAP, but sometimes everybody needs a little kick.
So this thread should collect suggestions of improvements of SAP coding. These suggestions should be very precise, so SAP should implement them easily. I'm pretty sure, everybody will find some not optimized code during debugging, learning, ... .
So , lets start with an example
Function module CO_SF_HEADER_GOODS_ISSUE
SELECT SINGLE * FROM caufv WHERE aufnr EQ aufnr.
There is no need for select *, because only the fields
autyp
loekz
objnr
gamng
gmein
rsnum
are needed during the FM.
so lets improve the code
select single aufnr loekz autyp gamng gmein rsnum
from caufv into (wa_caufv-aufnr,
                  wa_caufv-loekz,
                  wa_caufv-autyp,
                  gamng, gmein, rsnum)
With this code we can also kill three moves in the last lines.
MOVE: caufv-gamng TO gamng,
      caufv-gmein TO gmein,
      caufv-rsnum TO rsnum.
That was easy, on my testsystem it is 38% less database-time for the select and a little for the three moves.
What do you think?
Matthias

Answer 1

Not sure I'm on board,  I doubt SAP will take suggestions for modifying their code via a forum post, I think it is best to go thru OSS.
Anyway, a little story for ya.  We had a program which was sort of like CO41(collective planned order conversion), but was custom because we needed to include characterisics, so we have this program that gets all of the planned orders and then does CO40 transaction over each one.  This worked in the begining, but after some time the runtime was extremely bad, like hours long.  So I did some investigation and found the exact SELECT statement deep inside of CO40, and found that the WHERE clause was not written in such a way that was good for my company.  I contacted OSS, and pointed them to the exact place in the code that was giving us a problem.  I told them that the one line in the WHERE clause needed to b commented out, then the performance would be much better.  They came back after a number of days, and said, the SELECT statement was written in such a way that it works for all business processes.  At my company, our business process dictated that the one line in the WHERE clause was not necessary and even hurting our performance.  Anyway, they said they would not issue a change for us and that we either had to hack it ourselves or totally redo the way our task list groups where set up.  The problem was is that we had a couple task list groups, with thousands and thousands of materials assign to it. This was the problem.  So I hacked the standard program, and it actually shaved of 3 hours of processing time.
Regards,
Rich Heilman