Skip to Content

What is better in performance terms: A PERFORM or a CALL FUNCTION ?

Jun 28, 2017 at 05:14 PM


avatar image

Just curious,

What is better in performance terms: A PERFORM or a CALL FUNCTION ?

Suppose a simple code of getting a input parameter, maybe doing a couple of questions and/or strings transforms and then a SELECT from an external table. What would be faster?

Thanks in advance,


10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Matthew Billingham
Jun 28, 2017 at 06:52 PM

If I'm your team leader and you use PERFORMs, your performance appraisal will be notably worse than if you use CALL FUNCTION, but not as good as if you fully embrace object orientation - and use it properly.

All method calls, performs and function module* calls are internal calls. Unless the ABAP interpreter is really really bad, there will be no difference in the performance.

* Normal use - RFC and other variations excepted.

Show 11 Share
10 |10000 characters needed characters left characters exceeded


Thanks for your answer.

Generally I agree on the idea of using methods and functions but I'm afraid that my coworkers aren't too keen on them, and I worry about writing code that no one else (in my own, small group) likes to maintain :-)

Thanks again. I think I will change my more often used FORMs to functions (and/or methods) and see what happens.




You can always point out the FORMs and PERFORMs are obsolete in later versions. It's sad when programmers are averse to developing their skills and embracing new technologies (and doesn't say much for their skills!). We still see blogs and posts here by people who won't use any table type other than STANDARD - HASHED and SORTED have only been around for what, 18 years?! (As has ABAP Objects). It's career limiting, and prevents the exploitation of newer technologies, like the now aging web dynpro!


"Later versions"? FORM and PERFORM are already obsolete statements. See ABAPDOCU

(Maybe Horst should write the sentence "Subroutines are obsolete. In new programs, methods must be used instead." in big fat red in the documentation)


I was being diplomatic.

When did the documentation change? I'll bet there are some people still working on versions earlier than that. Personally, I think a performance hit for every perform run on a program created after 1.1.2010 would be a good incentive....


"All method calls, performs and function module* calls are internal calls. "

Hmm ...

In fact, we distinguish between internal calls of procedures of the same program and external calls of procedures of other programs. In the latter case, the external program must be loaded (if not already done), the event LOAD-OF-PROGRAM is triggered, ...

And there can be awkward effects in external procedure calls, especially for subroutines, depending on the call sequence. Read about the program groups ...


Yeah I know. I was simplifying. But external procedure calls... obsolete, no?


Of course not.

As a rule each call of a function module or a method of a global class from a client is an external procedure call.

Obsolete are external subroutine calls (PERFORM ... IN)

Not recommended are external calls of methods of local classes (dynamic CALL METHOD with absolute type names \PROG\CLASS\METH).


OK. But the end conclusion is that internal/external calls are unlikely to make a difference that makes it worth worrying about.


Yes, cause it's unlikely that you call a procedure of a different main program in each loop pass ;-)


Now that would be silly... but what if I created a dynamic program and executed a new dynamically created subroutine (using GENERATE SUBROUTINE POOL) for every pass of the loop ;)

I guess at that point as Luis says, no one else will want to maintain that code in the future.

Show more comments
Horst Keller
Jun 28, 2017 at 05:22 PM

You cannot ask this like that. You must ask if internal or external calls are faster. And for these it depends if the external program is already loaded or not. And b.t.w., there are also methods, which are the state-of-the-art procedures. There should be no difference between the different kinds of internal calls. Same for external calls.

Show 10 Share
10 |10000 characters needed characters left characters exceeded


Thanks for your answer. I'm somewhat of a newbie to SAP, I have done some ABAP programming, but my expertise is more in areas like C and SQL.

Ok. So let me rephrase it.

Would be an external call as fast as an internal one? Suppose it gets called (many times) from inside a loop.

Regarding methods, would they be as efficient as a function?

Thanks again,



It's faster to do a test yourself than asking the question.

The answer was very clear, I don't understand why you ask again the same question. Or do you think of something we should know?

As Horst answered for one call, then it will be the same for several calls (and no, there is no buffering of addresses or things like that).


Judging from his other comment, I think he was looking for a statement that PERFORMs are slower than function modules or methods, to show his colleagues.

@Horst - how about a language development where there's a delay for ever perform executed in code with a creation date later than 01.01.2018. And double the delay for every perform. That'll fix the luddites ;-)


Functions and methods, no difference.

Internal and external, once the external program is loaded, also about the same.

As Sandra said, it would be a good exercise to measure it.


Here are a few performance measures (same logic as program RSHOWTIM) - is the average time of 50 measures, each mesure does 1000 calls/performs (local static method, local perform) - ABAP 7.40 SP 7 and Kernel 742 SP 300 :

                              procedure with    procedure with 3 CHANGING 
                              0 parameter       parameters of type I, by reference

CALL METHOD static method     395               526

CALL METHOD instance method   435               580

PERFORM                       390               660

CALL FUNCTION                 710               1000

...and it took you six months to write that??? :-)

Just kidding, thanks. If you still have the code handy, it would be interesting if you could add a class instance, as instantiating is the preferred way to go. From memory I believe it has something to do with static classes being subject to different memory management, behaving more like a report.

Done. The call to instance method is 10% slower than call to static method (probably due to: "is the variable bound/pass the address of the instance").

Note: I had to adjust the measures for the instance methods so that they look consistent with the other measures, because the "run time numbers" for static methods were 30% lower than in the previous session (270 instead of 395, 370 instead of 526).


Interesting! Bigger difference than I expected. Still not earth-shattering.

As mentioned I vaguely remembered reading about instances being preferred... well I found the info again, in the good ol' online help:

Show more comments