Skip to Content
Technical Articles

Performance Analyzer Tool

First things first…this is a tool for lazy people that don’t want to spend some analysing the code they must apply Performance on.  I love Performance, and have worked on many Performance projects…have seen horrible codes with OCCURS 0, SELECT * and LOOP INTO WA.  I love RegEx, and I’m on my way to hopefully became an ABAP RegEx Hero.  So they other day I was just checking one program and an idea toss into my mind…why don’t write a program that scan the code for me and let me know what are the most obvious Performance problems in the source code.   At first, I tried to do something like the old and dead SE49… {code:html}Tasting the mix of PHP and SAP – Volume 11{code} but then I think to myself “Come on Blag! You know RegEx…let’s use it”…so this nice and somehow useful tool came to live -:) LIKE LINE OF T_DATA.  SELECT * INTO CORRESPONDING FIELDS OF TABLE T_SPFLI FROM SPFLI INNER JOIN SFLIGHT ON SPFLI~CARRID EQ SFLIGHT~CARRID WHERE SPFLI~CARRID EQ ‘JFK’   AND COUNTRYTO EQ ‘PE’.  LOOP AT T_SPFLI. ENDLOOP.   So, we call our program and pass the report name as the parameter… image When we executed, we’re going to see the line, the bad code, a possible solution and the name of the program…because yes…it can handle includes -;) image
You must be Logged on to comment or reply to a post.
    • Neil:

      Sorry man…but I need to show the rest of the world your coding vices -;)

      And sure…RegEx is awesome…can break your head something, but it’s really some worth to take a look -;)


  • It does seems like a cool tool, and a good example of using regular expressions, but…

    To be honest I think that most of the checks that you are making are overrated. I have yet to find a program with performance problems that could be (significantly) improved by changing LOOP INTO to LOOP ASSIGNING, or for example by not using CORRESPONDING. I think these are the kind of things that give QA reviewers a bad name: how can you justify your job if what you do is bother abapers with changes that improve the runtime in 0,001%?

    Just my two cents…

    • Rui:

      I didn’t “build” this tool to be used by QA reviewers…I build it because I love RegEx and because most of the time when I have to do Performance tasks, believe or not, most of the problems are that programmers didn’t use Field-Symbols or used INTO CORRESPONDING FIELDS. And BTW, I have improved at lot of program just by replacing INTO WA for ASSIGNING -;)

      I appreciate your comments, but keep in mind that I’m not presenting this tool as the ultimate tool…but as toy to play with and save a little bit of time while reviewing someone else code…


      • (really don’t want to start a discussion about this, but..)

        ok, you must then be very lucky and be working in a near perfect system if most of your problems can be solved by changing INTO WA for ASSIGNING. If you follow the ABAP performance forum, for example, there is rarely a situation that can be improved with those “details”. I agree with David Hull’s comment about these small tuning changes (if I can easily make a 0,1% improvement in a program, why not do it?) but that doesn’t mean they can solve a report with performance problems.

        (I made the last person that showed be this kind of improvement to revert back to INTO WA, and magic: the program was still fast; the next day, after caching effects had disappeared, both versions were again slow)

        That said, I did start my 1st comment by saying that the tool was cool and a good example of using REGEX.

    • Well, first of, Blag posted this as a proof of concept of what you can do with Regular Expressions… not as a be-all, end-all, performance analysis tool.  So you fill in the blanks about what is important, in your environment, to search for.

      Secondly, Blag is an abaper, not a “QA reviewer”.

      And lastly, when you run systems like I do with tens of thousands of concurrent users, and many millions of database reads/writes per hour, you’ll find that even relatively small tuning changes can make a very big difference in system performance.

      Of course, I should not even need to mention the many, many obviously poorly coded programs that make it to the QA process due to less-than-skilled programmers.  What better than an automated tool for them to run that can point out such errors?

      I say bravo, Blag, it’s a great idea!


      • Alvaro, sorry for keeping this off-topic discussion.

        Naimesh, thanks for the link. Performance advantages of LOOP ASSIGNING vs LOOP INTO are well known and well documented (they even appear in SE38 performance examples, which are quite old). My point is that I see too many people that seem to focus on INTO CORRESPONDING and LOOP ASSIGNING and whatever, and forget the things that can really significantly improve a program performance. Just think: in your own program example, that was created specifically to demonstrate the advantage of LOOP ASSIGNING, how much time is spent with the MODIFY (vs the time spent in the SELECT to BSEG)? Probably less than 10%, and this in a program specifically created to show that MODIFY by index is bad!

        Most of performance problems I see (or almost all) arise from either bad database access (no/bad index usage) or internal table operations over non-sorted tables. The rest can also be important, but sometimes other factors like readability and maintainability can be more important than the performance. Personally I usually would not bother an abaper if the only “horrible” (to use Alvaro’s word) thing I see in the code is an INTO CORRESPONDING.

        Rui Dantas

  • Blag:

      Interesting blog.  While your said it’s a performance check, it seems to be a code walkthrough check.  Which is fine, though as other commenters said, one needs to know what to look for first.
      Over 10 years ago, as I recall, a fellow ASUG member presented a tool they built to read ABAP and find common coding errors.  We thought that was great, but their legal people decided it could not be shared.  So our Basis manager commissioned our top ABAP programmer to write one for us.  The coder said that was much harder to write than she originally thought.  We could not share our code either, though if it’s still around I could probably cast it into pseudo-code for documentation purposes.
      Several years later, SAP released the “SAP Code Inspector” – transaction SCI, which allows for canned code grammar checks.  For help, see:  While Code Inspector is powerful, the user interface is daunting, at least to me.  Your program seems easier for ad hoc reviews looking for specific text patterns.
      How will you measure the performance gains, compared to the effort to rip out and install replacement code, run the code up through transports and verify no side effects?

    • Jim:

      Just a few notes…
      >While your said it’s a performance check, it seems to be a code walkthrough check.

      What I say was…”why don’t write a program that scan the code for me and let me know what are the most obvious Performance problems in the source code.” I never said it was a Performance check, but a Performance Analyzer…maybe the title is not the best, but I state very clear that I scan code and get problems in source code.

      >How will you measure the performance gains, compared to the effort to rip out and install replacement code, run the code up through transports and verify no side effects?

      As I said, this is a this is a tool for lazy people that don’t want to spend some analyzing the code they must apply Performance on. You will know which lines you have to look at and most important, what are the most common error you must fix.

      This tool born more like a way to use RegEx in a helpful way…so it could be a Code check or a Calculator… -;)


  • I see that blog just now after half a year. And I must say, that I am not convinced.

    I do not know what you define as performance problem, but they major checks for performance are included in the Code Inspector (SCI), whích is available for several years already.

    Major problems which be checked in the source code are
    + index problems with databases, no first kef field of any index is used
    + problems with table buffers mainly bypassing buffers
    + problems with usage of internal table (again now index, here it is called sorted table or hashed table).

    All these checks are implemented in the SCI, they are no simple code checks but cross checks requiring definition of the data.

    Many performance problems can not be identified in the source code only and require a trace analysis.

    Assigning in internal tables, field lists in DB selects are not on the same level. They can improve the performance but they are only nice to have effects. IN CORRESPONDING is a zero effect.


    • Siegfried:

      I agree…but keep in mind that I build this more as a way to show what can be done using RegEx…take it more as a community project that be improved by others -;)