Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

What are your most frustrating experiences reg. (ABAP) Performance?

former_member192616
Active Contributor
0 Kudos

Hi,

i would be interested in the following:

When it comes to (ABAP) Performance (Analysis / Tuning), what are your most frustrating experiences?

Some examples from my frustrating experiences:

- when the time is not spent in the ABAP stack, it regularly starts to get frustrating for me.

- when the time is spent on a single SQL statement and i am not able to come up with a suggestion, this can be frustrating as well . (Fortunatelly i have some colleagues that might help me then)

- when the time is spent in several software layers (frameworks) that perform lots of (identical) calls and a application or business process knowlegde is required (that sometimes can not be found easily) this is often frustrating as well.

- tbc. ...

So, what are your frustrating experiences?

@Moderators if you think this posting belongs not in this forum feel free to move it to a more appropriate place... .

Kind regards,

Hermann

11 REPLIES 11

Former Member
0 Kudos

This is the sort of thing that does belong here. These forums aren't just for people trying to solve problems. Interesting discussions are more than welcome.

I was going to say - going through standard SAP code and finding multiple identical SELECTs. But I think you covered that in your last point.

Rob

0 Kudos

Poor functional specs can be frustrating, when you don't know how to convert this into a good technical design that allows for good performance. Luckily I'm writing my own functional specs by now.

Growing databases are also a pain, because archiving projects are often lower priority than all the other urgen-t stuff. We have about 140 million FI documents and counting, slowing down even optimized data accesses.

Finally, getting hit on the head by Siegfried can be frustrating, in a positive sense...

Thomas

former_member194613
Active Contributor
0 Kudos

I don't really understand the purpose of this discusson:

I can not actually say, that the most NOT frustrating experiences are simple errors, which can easily be fixed, such that the result is by factors faster. .

When I think about frustrating experiences, that I come directly to the well known pseudo recommendations:

  • Replace your Join by FOR ALL ENTRIES* and

  • the INTO CORRESPONDING FIELDS kills your performance*

  • avoid nested loops *.

....

Siegfried

former_member192616
Active Contributor
0 Kudos

Hi,

thanks for your replies. There is no real "purpose" more curiosity what other people find frustrating

or if i may rephrase it:what other peolpe find difficult or struggle with.

E.g. Personally i never happend to had a case where archiving played a role. Maybe because in many places

i worked archiving was in place an in other places missing archiving was not an issue yet. Would be interesting to see such a case though.

And yes misleading recommendations here in the forum (and sometimes you find them in development guidelines too) can be frustrating as well.

So i was just curios what bothers other people besides those things that are posted here.

Kind regards,

Hermann

0 Kudos

The most frustrating things/observations for me are:

1. To give the best recommendations "that helps the system overall" in some good performance issue, a good knowledge of the application area is very helpful and many a times this knowledge would change the optimization paths otherwise suggested technically. This has been my experience.

2. Identical selects....its frustrating to see identical selects(many of which seem to be due to the concept of code reusability..for example in function modules) and not able to do anything as it would be a design change.

Former Member
0 Kudos

Ok, you're asked for it and I cannot resist this invitation for ranting...

My top frustrating experience for any performance analysis/tuning is seeing poorly written programs by people who don't care. And I'm not talking about some missing fine tuning here or the occasional glitch, but the stuff that gives us grey hairs when we actually have to support it. My personal feeling is that within the ABAP world there's lots people without any interest or experience in programming and it clearly shows.

Unfortunately within ABAP programs we often have funky business logic - after all, that's why we have to code the stuff, because it's not present in standard SAP. Not all user requirements make sense, but too often you have consultants who don't understand or care enough to say no to some requests. If you then get a programmer who doesn't care and doesn't know how to program properly, you'll end up with a piece of code that cannot be maintained properly. Due to the usual time/money constraints the downward spiral of making minimal changes (instead of proper rewrite) for bug fixes and new features starts.

In the end I'm really venting against poor attitude. Errors are unavoidable and newbies are more than welcome to make their share (after all, even the experienced people won't stop making mistakes). However, if a programmer doesn't think further than using FOR ALL ENTRIES as a magic bullet, doesn't even understand database joins and doesn't care, then I think they're in the wrong business and should do something else.

So to me it's similar like reading the forums: You want to have your fair share of interesting discussions without discouraging newbies to ask their questions. However, if you see that not even an iota of research was done before asking a question, you get tired and would like to revert back to the classic RTFM. After all, we just have limited time and would like to have the feeling we utilized it well...

I apologize for my long rampage, but that's what happens with all this suppressed anger - Cheers, harald

0 Kudos

very well said!

Thomas

0 Kudos

Hello,

As a basis guy I'm often frustrated by junior ABAP developers, even experienced once.

In my opinion every ABAP developer should focus more on performance, there are some very good books and SDN topics on this.

This is my contribution :

1/

Nested loops on internal tables causing high CPU load.

2/

Incorrect use of internal tables, often a simple standard internal table is used in stead of sorted or hashed tables.

3/

Incorrect de-allocation of memory.

Trust me a REFRESH itab is not the same as a FREE itab...

4/

Too many switches between DB server and application server often caused by :

LOOP at itab.

A lot of selects here ...

ENDLOOP.

Personally this is performance killer one.

Correct LUW should be : Select all the data in workfields from DB, process the data on app server, write back data to DB.

5/

Don't try to read large files in an internal table at once.

Process your data in blocks (example 10.000), so your program not only works on DEV with small datasets but also in PRD with large datasets.

Same counts for select statements with a big result set.

With a SELECT INTO ITAB you have no control at all about how many records will end up in the internal table.

Often this causes short dumps in PRD, memory overflows, ...

Only few ABAP developers (or developers in general) know how to correctly work with large volumes when it comes to memory usage.

I hope this helps.

Wim

0 Kudos

Hi Harald,

thanks for your interesting post.

I felt the same when the "type of person" described by you was among my colleagues.

Since it changed and they are among my customers this changed a little bit...

However i still can feel you pain.

Kind regards,

Hermann

0 Kudos

Hello,

Well, I had some weird experience about performance.

First a project with quality procedure and performance rules you must stricly follow.

Nevertheless, some of them where wrong ( extended use of For all entries), all data in internal table without care of the size of the extract. No use of typed internal table and so on...

And each time we try to make thing move we can't.

Another is more general as customer want quick reponse and solution to their problem (with minimum testing from their side), we often try to fix with small patches to correct locally bug or small evolution. Often without reading and understanding the whole, so we see multiple select on the same table to read the same data, or another field. This phenomena seems to increase with the number of developper maintaining the same program.

I also see an increasing number of multiple 'INNER JOIN' in the same select the max I meet was 5. SAP server was slowed down only with this program.

There is also an performance issue which is interesting, for which ABAP can't cope : Customizing eg SELECT with index field in a table with only 1 value for the whole table so index is useless.

Christophe

Former Member
0 Kudos

Hi,

I'm a BASIS and we had a lot of issues with in-experience programmer. Below some of low-point which I can share based on my experience.

1. For testing, ABAP programmer never test against performance. They just test on getting the correct result. It is seldom to find a programmer that know how to do a technical test, performance stress test, CATT and those in ST30.

2. Exception error which are not handle properly with a proper message, hence it is always seen as system error.

3. Some of the junior programmer and sometimes senior are not aware on the correct way how to create an index. I believe I had open a forum on this.

I've asked my ABAP programmer to check, but ya not sure if they go it or read it.

4. I'm not sure if a programmer know how to use t-code ST05. This is because, when I asked them to check, they like to go to debug mode and execute the line of code line by line. So, I'm not sure what is their approach when performing program tuning.

5. Concept of OO (Object Oriented). Some of the function are not put as function module, hence they need to change each occurrence of the problem code.

6. Approach on performance tuning.

I had an experience with one external company (I guess it happen in my current company too) they analyze the hold program instead of finding it from ST05.

BR,

Eida