Skip to Content

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

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,


Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Best Answer
    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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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....

  • 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.

    Add comment
    10|10000 characters needed characters exceeded

    • Yes, compared to the actual content execution it's tiny.

      As an aside, I gather this is the reasoning behind not going overboard on Java-style getters and setters everywhere:

      From the docu:

      "However, the modularization at the level of a few single statements is and will remain untypical for ABAP. On the one hand this is because of performance reasons, because the costs for the method call must remain low in comparison to the costs for executing the implementation. For example, instead of providing the get_attribute methods typical for other object-oriented languages that only set their return value to the value of an attribute attribute, you should use public READ-ONLY attributes in ABAP. (If reads on an attribute are associated with further actions, for example, authorization checks, get_attribute methods are appropriate of course.)"