Skip to Content

In my previous DO and DO while praising DO..ENDDO construct I have placed a warning on possible OO exception overhead when using TRY…ENDTRY instead. My preconceived idea looked very obvious to me – I thought that OO exception mechanism should have quite a reasonable impact on perfomance.

And after reading Horst Keller comment on that weblog (thanks Horst!) I decided to clarify this at least to myself. And now I present the results to you.

First, I have written a simple test program to check different techniques of raising exceptions. Here you can see five subroutines. In each subroutine the statement of my interest is placed within quite long loop, just to minimize sporadic events influence and to make timings more stable.

First subroutine contains four nested IFs – the construct I consider to be quite unreadable and ugly. Anyway, as I expect, it should give the shortest execution time. The essential part of the each subroutine is a sequence of internal table READs, which is quite common code pattern for nested IF. The sequence is deliberately created to make sure that only the last READ would be successfull.

FORM test_if_endif USING value(pernr). DO 100000 TIMES. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = pernr BINARY SEARCH. IF sy-subrc NE 0. CONTINUE. ENDIF. ENDIF. ENDIF. ENDIF. ENDDO. ENDFORM. "test_if_endif

Next subroutine contains DO 1 TIMES…ENDDO loop as a replacement for nested IF.

FORM test_do_enddo USING value(pernr). DO 100000 TIMES. DO 1 TIMES. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. CHECK sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. CHECK sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. CHECK sy-subrc NE 0. READ TABLE tab INTO wa WITH KEY pernr = pernr BINARY SEARCH. CHECK sy-subrc NE 0. ENDDO. ENDDO. ENDFORM. "test_do_enddo

The following subroutine is a sample of using TRY..ENDTRY with raising exception of a particular type without creating its instance (RAISE EXCEPTION TYPE).

FORM test_try_endtry USING value(pernr). DO 100000 TIMES. TRY. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. CATCH cx_root. ENDTRY. ENDDO. ENDFORM. "test_try_endtry

The following subroutine is a sample of using TRY..ENDTRY with raising exception with previously created instance (RAISE EXCEPTION ex). The instance was created before subroutine call.

FORM test_try_endtry_with_instance USING value(pernr). DO 100000 TIMES. TRY. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION ex. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION ex. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION ex. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION ex. ENDIF. CATCH cx_root. ENDTRY. ENDDO. ENDFORM. "test_try_endtry_with_instance

The last subroutine is a sample of raising exception with creating an instance in CATCH clause (CATCH … INTO).

FORM test_try_endtry_with_instance1 USING value(pernr). DATA: ex TYPE REF TO cx_root. DO 100000 TIMES. TRY. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. READ TABLE tab INTO wa WITH KEY pernr = space BINARY SEARCH. IF sy-subrc = 0. RAISE EXCEPTION TYPE cx_alert. ENDIF. CATCH cx_root INTO ex. ENDTRY. ENDDO. ENDFORM. "test_try_endtry_with_instance1

I tested the program containing all subroutines by Runtime Analysis tool (SE30). Testing environment: SAP_BASIS – 6.20, WAS Operating system – HP-UX, RDBMS – ORACLE 9.2.0.5.0. I was the only user online and there were no background tasks.

Now, the results from SE30. I remind you that all timings are in microseconds.

First picture shows execution times of subroutines when READ TABLE statement ends successfully (sy-subrc = 0) and in that case exception CX_ALERT is raised in three subroutines.

image

Next picture show the results when none of READ statement was successfull and so the exception was not raised.

image

An interesting result (at least for me) is that preliminary creation of an OO exception instance (subroutime try_endtry_with_instance) has negative impact on performance, and in that case an overhead is around 0,7 microsecond per raising an exception comparing to raising exception with type (RAISE EXCEPTION TYPE …).

Another theoretical result is that DO 1 TIMES…ENDDO is slightly slower than TRY…ENDTRY without raising and exception.

What could be the practical conclusions?

  • First, raising exception with statement RAISE EXCEPTION TYPE has no essential overhead. In my test it cost only 1 microsecond. Very subtle.
  • Second, catching exception with instance creation (CATCH … INTO …) cost around 20 microseconds. So, when processing one million record internal table you can potentially gain 20 sec by avoiding such an exception catch method within loop. Is it worth something? Not very much, I guess.

All in all, I really impressed by the results and plan from now on to use TRY…ENDTRY instead of nested IF where possible.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Joschka Rick

    Hi Sergei. Thank you for this insight. I’m surprised that raising an instanciated exception costs more than raising a new one. It’s rather against the common sense. Good to know!

    Can you explain why SAP behaves like that?

    Cheers and best regards, Joschka.

    (0) 

Leave a Reply