Performance der neuen 7.40-Syntaxen
Beitrag
von DeathAndPain (Top Expert / 2029 / 274 /
426
)
»
Hallo zusammen,
hat sich eigentlich mal jemand die Mühe gemacht, die Performance der neuen 7.40-Syntaxen zu messen und den Vergleich zu den alten darzustellen? Gibt es dazu eine Webseite? Das wäre mal interessant.
Kürzlich hatte hier ja schon jemand (adt?) angemerkt, dass die neue filter-Funktion wohl ziemlich schlecht performt. Aber was ist mit dem, was man am meisten braucht: Klassische Zugriffe auf sortierte interne Tabellen?
Ich habe mir mal den Spaß gemacht, die neue Syntax dem klassischen READ TABLE gegenüberzustellen. Ich fand, dass LINE_EXISTS() in der Tat besser performt als ein READ TABLE...TRANSPORTING NO FIELDS mit nachfolgendem Vergleich auf SY-SUBRC (ca. Faktor 3).
Doch in dem Moment, in dem man mehr will als nur eine Prüfung auf Existenz, dreht sich das Verhältnis drastisch um! Dann braucht man nämlich bei der neuen Syntax den hässlichen TRY...CATCH...ENDTRY-Block aus der Objektorientierung, da man ja immer damit rechnen muss, dass eine gesuchte Zeile mal nicht existieren könnte. Und da musste ich feststellen, dass
DATA I0000 LIKE SORTED TABLE OF PA0000 WITH UNIQUE KEY PERNR ENDDA WITH HEADER LINE.
TRY.
I0000 = I0000[ PERNR = '12345678' ENDDA = '99981231' ].
CATCH CX_SY_ITAB_LINE_NOT_FOUND.
CLEAR I0000.
ENDTRY.
bei Nichtvorhandensein der Tabellenzeile ungefähr siebenmal so viel Rechenzeit verbraucht wie
READ TABLE I0000 WITH KEY PERNR = '12345678' ENDDA = '99981231'.
IF SY-SUBRC <> 0.
CLEAR I0000.
ENDIF.
Das finde ich sehr drastisch! Da sieht man mal, was für einen hohen Rechenzeitpreis man bezahlt, wenn man dieses objektorientierte Geraffel einsetzt.
Man kann hier 7.40-Syntax auch ohne Objektorientierung nutzen, indem man schreibt:
ASSIGN I0000[ PERNR = '12345678' ENDDA = '99981231' ] TO FIELD-SYMBOL(<I0000>).
IF SY-SUBRC <> 0.
CLEAR I0000.
ENDIF.
Das braucht nur geringfügig mehr Rechenzeit als die READ TABLE-Variante (ca. 6%). Immerhin bedeutet das aber, dass es dennoch langsamer ist, und das fällt auf, wird doch hier nur ein Feldsymbol zugewiesen, anstatt die Fundstelle in ein Feld umzukopieren, was ja im Regelfall der langsamere Weg zu sein pflegt. Der Löwenanteil des Zeitverlustes geht also tatsächlich auf die Kappe von TRY...CATCH...ENDTRY.
Gibt es die Tabellenzeile, so dass TRY...CATCH...ENDTRY keine Exception zu verarbeiten hat, dann performt die erste Syntax besser als der ASSIGN und beinahe so gut wie der READ TABLE, der aber dennoch ganz knapp die Performancekrone behält. In diesem Fall liegen aber alle drei Varianten so dicht beieinander, dass es kaum einen Unterschied macht.
In den meisten Programmen wird die Rechenzeit auf dieser Ebene unerheblich sein. Hat man aber Code mit sehr intensiver Tabellennutzung, etwa bei intensivem Lesen aus Puffertabellen, dann kann ich mir schon vorstellen, dass man einiges an Rechenzeit einsparen kann, wenn die erste Syntax nur in Fällen nutzt, in denen das Nichtvorhandensein der Zeile zumindest sehr selten sein wird.
Wie gesagt, es würde mich interessieren, ob es noch mehr derartige Vergleiche gibt und die vielleicht irgendwo publiziert worden sind.
hat sich eigentlich mal jemand die Mühe gemacht, die Performance der neuen 7.40-Syntaxen zu messen und den Vergleich zu den alten darzustellen? Gibt es dazu eine Webseite? Das wäre mal interessant.
Kürzlich hatte hier ja schon jemand (adt?) angemerkt, dass die neue filter-Funktion wohl ziemlich schlecht performt. Aber was ist mit dem, was man am meisten braucht: Klassische Zugriffe auf sortierte interne Tabellen?
Ich habe mir mal den Spaß gemacht, die neue Syntax dem klassischen READ TABLE gegenüberzustellen. Ich fand, dass LINE_EXISTS() in der Tat besser performt als ein READ TABLE...TRANSPORTING NO FIELDS mit nachfolgendem Vergleich auf SY-SUBRC (ca. Faktor 3).
Doch in dem Moment, in dem man mehr will als nur eine Prüfung auf Existenz, dreht sich das Verhältnis drastisch um! Dann braucht man nämlich bei der neuen Syntax den hässlichen TRY...CATCH...ENDTRY-Block aus der Objektorientierung, da man ja immer damit rechnen muss, dass eine gesuchte Zeile mal nicht existieren könnte. Und da musste ich feststellen, dass
DATA I0000 LIKE SORTED TABLE OF PA0000 WITH UNIQUE KEY PERNR ENDDA WITH HEADER LINE.
TRY.
I0000 = I0000[ PERNR = '12345678' ENDDA = '99981231' ].
CATCH CX_SY_ITAB_LINE_NOT_FOUND.
CLEAR I0000.
ENDTRY.
bei Nichtvorhandensein der Tabellenzeile ungefähr siebenmal so viel Rechenzeit verbraucht wie
READ TABLE I0000 WITH KEY PERNR = '12345678' ENDDA = '99981231'.
IF SY-SUBRC <> 0.
CLEAR I0000.
ENDIF.
Das finde ich sehr drastisch! Da sieht man mal, was für einen hohen Rechenzeitpreis man bezahlt, wenn man dieses objektorientierte Geraffel einsetzt.
Man kann hier 7.40-Syntax auch ohne Objektorientierung nutzen, indem man schreibt:
ASSIGN I0000[ PERNR = '12345678' ENDDA = '99981231' ] TO FIELD-SYMBOL(<I0000>).
IF SY-SUBRC <> 0.
CLEAR I0000.
ENDIF.
Das braucht nur geringfügig mehr Rechenzeit als die READ TABLE-Variante (ca. 6%). Immerhin bedeutet das aber, dass es dennoch langsamer ist, und das fällt auf, wird doch hier nur ein Feldsymbol zugewiesen, anstatt die Fundstelle in ein Feld umzukopieren, was ja im Regelfall der langsamere Weg zu sein pflegt. Der Löwenanteil des Zeitverlustes geht also tatsächlich auf die Kappe von TRY...CATCH...ENDTRY.
Gibt es die Tabellenzeile, so dass TRY...CATCH...ENDTRY keine Exception zu verarbeiten hat, dann performt die erste Syntax besser als der ASSIGN und beinahe so gut wie der READ TABLE, der aber dennoch ganz knapp die Performancekrone behält. In diesem Fall liegen aber alle drei Varianten so dicht beieinander, dass es kaum einen Unterschied macht.
In den meisten Programmen wird die Rechenzeit auf dieser Ebene unerheblich sein. Hat man aber Code mit sehr intensiver Tabellennutzung, etwa bei intensivem Lesen aus Puffertabellen, dann kann ich mir schon vorstellen, dass man einiges an Rechenzeit einsparen kann, wenn die erste Syntax nur in Fällen nutzt, in denen das Nichtvorhandensein der Zeile zumindest sehr selten sein wird.
Wie gesagt, es würde mich interessieren, ob es noch mehr derartige Vergleiche gibt und die vielleicht irgendwo publiziert worden sind.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
4byte
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4159 / 136 /
960
)
»
Moin D&P,DeathAndPain hat geschrieben:Dann braucht man nämlich bei der neuen Syntax den hässlichen TRY...CATCH...ENDTRY-Block aus der Objektorientierung
[...]
Da sieht man mal, was für einen hohen Rechenzeitpreis man bezahlt, wenn man dieses objektorientierte Geraffel einsetzt.
Ein Try-Catch-Block ist eine Ausnahmebehandlung. Und die hat mitnichten etwas mit Objektorientierung zu tun sondern ist ein ganz allgemeines Programmierkonzept. Wenn du kein OO magst ist das ja deine Sache und du darfst auch gerne über schlechte Performanz von neuen Sprachelementen meckern. Aber bitte nicht so darstellen bloß um OO schlecht dastehen zu lassen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Haubi
Beitrag
von AdrianSchm (ForumUser / 33 / 4 /
4
)
»
Die neue Syntax ist echt cool. Man kann nun 100 Befehle in einer Zeile Schachteln.
Sowas wie das hier:
Sowas wie das hier:
Code: Alles auswählen.
DATA(ls_alv) = VALUE ts_alv( key = <ls_epdproda>-keyattr
attrid = <ls_epdproda>-attrid
parameter = COND #( WHEN <ls_epdproda>-evaltype EQ 'P'
THEN <ls_epdproda>-value
ELSE space )
value = me->as_value_for_output( iv_rollname = <ls_epdproda>-datatype
iv_value = me->get_value_from_attrid( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) )
descript = <ls_epdproda>-scrtext_l
style = VALUE #( ( fieldname = 'VALUE'
style = COND #( WHEN <ls_epdproda>-evaltype NE 'P'
OR ( <ls_epdproda>-create_only EQ abap_true
AND me->mr_gui->mo_tree->get_node_properties( <ls_epdproda>-node )-aemode EQ lcl_tree=>mc_node_update )
OR gv_mode EQ lcl_gui=>mc_mode_show
OR ( <ls_epdproda>-evaltype EQ 'P'
AND me->get_status_from_parameter( <ls_epdproda>-value ) EQ lcl_tree=>mc_node_done )
THEN COND #( WHEN me->is_attrid_checkbox( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) EQ abap_true
THEN COND #( WHEN me->get_value_from_attrid( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) EQ abap_true
THEN alv_style_checkbox_checked + cl_gui_alv_grid=>mc_style_disabled
ELSE alv_style_checkbox_not_checked + cl_gui_alv_grid=>mc_style_disabled )
ELSE cl_gui_alv_grid=>mc_style_disabled )
ELSE COND #( WHEN me->mr_gui->mo_tree->read_node_status( <ls_epdproda>-node ) EQ abap_true
AND <ls_epdproda>-oblig EQ abap_true
AND <ls_epdproda>-keyattr NE abap_true
AND me->is_attrid_checkbox( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) NE abap_true
AND me->get_value_from_attrid( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) IS INITIAL
THEN alv_style_color_negative + cl_gui_alv_grid=>mc_style_enabled + alv_style_f4
WHEN me->mr_gui->mo_tree->read_node_status( <ls_epdproda>-node ) EQ abap_undefined
AND ( <ls_epdproda>-execution EQ abap_true
OR <ls_epdproda>-keyattr EQ abap_true )
THEN alv_style_color_total + cl_gui_alv_grid=>mc_style_enabled + alv_style_f4
ELSE COND #( WHEN me->is_attrid_checkbox( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) EQ abap_true
THEN COND #( WHEN me->get_value_from_attrid( iv_node = <ls_epdproda>-node
iv_attrid = <ls_epdproda>-attrid ) EQ abap_true
THEN alv_style_checkbox_checked + cl_gui_alv_grid=>mc_style_enabled
ELSE alv_style_checkbox_not_checked + cl_gui_alv_grid=>mc_style_enabled )
ELSE cl_gui_alv_grid=>mc_style_enabled + alv_style_f4 ) ) ) )
( fieldname = 'DESCRIPT'
style = cl_gui_alv_grid=>mc_style_disabled ) ) ).Der Vergleich ist auf jeden Fall interessant.
An dem objektorientierten Geraffel liegt es jedoch nicht.
Ich habe in den zweiten READ auch eine Exception eingebaut. Das ändert nichts (messbares) an der Laufzeit.
An dem objektorientierten Geraffel liegt es jedoch nicht.
Ich habe in den zweiten READ auch eine Exception eingebaut. Das ändert nichts (messbares) an der Laufzeit.
Code: Alles auswählen.
*DATA persons TYPE standard TABLE OF pa0000 WITH DEFAULT KEY.
DATA persons TYPE SORTED TABLE OF pa0000 WITH UNIQUE KEY pernr endda .
*DATA persons TYPE SORTED TABLE OF pa0000 WITH UNIQUE KEY pernr subty objps sprps endda begda seqnr.
CLASS lcx_test DEFINITION INHERITING FROM cx_static_check.
ENDCLASS.
START-OF-SELECTION.
SELECT * FROM pa0000 INTO TABLE persons up to 1 rows.
DATA(person) = persons[ 1 ].
DO 1000000 TIMES.
person-pernr = sy-index.
INSERT person INTO TABLE persons.
ENDDO.
PERFORM a1.
PERFORM a2.
PERFORM a3.
FORM a1.
GET RUN TIME FIELD DATA(start).
TRY.
person = persons[ pernr = '12345678' endda = '99981231' ].
CATCH cx_sy_itab_line_not_found.
ENDTRY.
GET RUN TIME FIELD DATA(stopp).
DATA(diff) = stopp - start.
WRITE: / '1:', diff.
ENDFORM.
FORM a2.
GET RUN TIME FIELD DATA(start).
TRY.
READ TABLE persons WITH KEY pernr = '12345678' endda = '99981231' TRANSPORTING NO FIELDS.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE lcx_test.
ENDIF.
CATCH lcx_test.
GET RUN TIME FIELD DATA(stopp).
DATA(diff) = stopp - start.
WRITE: / '2:', diff.
ENDTRY.
ENDFORM.
FORM a3.
GET RUN TIME FIELD DATA(start).
ASSIGN persons[ pernr = '12345678' endda = '99981231' ] TO FIELD-SYMBOL(<person>).
IF sy-subrc <> 0.
ENDIF.
GET RUN TIME FIELD DATA(stopp).
DATA(diff) = stopp - start.
WRITE: / '3:', diff.
ENDFORM.
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Zumal mich überhaupt nicht wundert, wenn OO-Coding grundsätzlich mehr Performance braucht, es gibt ja einen entsprechenden Overhead. Ich gehe deshalb auch davon aus, dass mehr Speicher benötigt wird.
Ich habe noch nie wen behaupten hören, dass dem nicht so ist. Der Schwerpunkt bei OO ist ja ein anderer. Würden wir den Fokus nur auf die Laufzeit setzen, müssten wir in Assembler programmieren und hätten erheblich mehr Aufwände.
Ralf
Ich habe noch nie wen behaupten hören, dass dem nicht so ist. Der Schwerpunkt bei OO ist ja ein anderer. Würden wir den Fokus nur auf die Laufzeit setzen, müssten wir in Assembler programmieren und hätten erheblich mehr Aufwände.
Ralf
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4484 / 231 /
1205
)
»
Warum das TRY...CATCH-Beispiel soviel mehr an Laufzeit braucht ist rasch erklärt:
Es handelt sich um eine Ausnahme und da muss der Kernel die aktuelle Verarbeitung unterbrechen, alle Informationen (Speicherabbild usw.) sammeln und eine teure "Sprung"-Operation zum CATCH-Block durchführen.
Deswegen nimmt man so ein Konstrukt ja auch nicht für den Standardanwendungfall (hier "Prüfen ob vorhanden") sondern für den absoluten Fehlerfall, wo man nicht mehr anders kann als den Programmabschnitt zu verlassen.
Genau dafür hat die SAP ja auch den LINE_EXISTS eingeführt, dass eben KEINE Exception ausgelöst wird.
Wo man das TRY...CATCH derzeit leider (noch) in einem Standardanwendungsfall braucht ist beim Typecast auf eine übergeordnete Klasse:
EDIT: Aber da ist Licht am Ende des Tunnels (namentlich ABAP 7.50)
https://blogs.sap.com/2015/10/21/abap-n ... stance-of/
Es handelt sich um eine Ausnahme und da muss der Kernel die aktuelle Verarbeitung unterbrechen, alle Informationen (Speicherabbild usw.) sammeln und eine teure "Sprung"-Operation zum CATCH-Block durchführen.
Deswegen nimmt man so ein Konstrukt ja auch nicht für den Standardanwendungfall (hier "Prüfen ob vorhanden") sondern für den absoluten Fehlerfall, wo man nicht mehr anders kann als den Programmabschnitt zu verlassen.
Genau dafür hat die SAP ja auch den LINE_EXISTS eingeführt, dass eben KEINE Exception ausgelöst wird.
Wo man das TRY...CATCH derzeit leider (noch) in einem Standardanwendungsfall braucht ist beim Typecast auf eine übergeordnete Klasse:
Code: Alles auswählen.
data:
lr_car type ref to zcl_car
lr_object type ref to object.
try.
lr_car ?= lr_object.
catch cx_sy_move_cast_error.
" ... Kein Auto
endtry.https://blogs.sap.com/2015/10/21/abap-n ... stance-of/
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ralf.wenzel
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 2029 / 274 /
426
)
»
Du meinst, weil es sich bei der Ausnahme CX_SY_ITAB_LINE_NOT_FOUND, um die es hier geht, nicht um eine Klasse handelt, die nicht von einer Oberklasse erbt, die nicht von einer Oberklasse erbt... Das ist schon was ganz anderes als etwa eine Ausnahme eines Funktionsbausteins, und zwar offensichtlich auch von der Rechenzeit her.black_adept hat geschrieben:Moin D&P,DeathAndPain hat geschrieben:Dann braucht man nämlich bei der neuen Syntax den hässlichen TRY...CATCH...ENDTRY-Block aus der Objektorientierung
[...]
Da sieht man mal, was für einen hohen Rechenzeitpreis man bezahlt, wenn man dieses objektorientierte Geraffel einsetzt.
Ein Try-Catch-Block ist eine Ausnahmebehandlung. Und die hat mitnichten etwas mit Objektorientierung zu tun sondern ist ein ganz allgemeines Programmierkonzept. Wenn du kein OO magst ist das ja deine Sache und du darfst auch gerne über schlechte Performanz von neuen Sprachelementen meckern. Aber bitte nicht so darstellen bloß um OO schlecht dastehen zu lassen.
Ich finde Deinen Code unglücklich, weil Du jeweils nur eine einzige Ausführung misst, wodurch so kleine Werte entstehen, dass der Rundungsfaktor erheblich wird. Dennoch komme ich auch mit Deinem Code auf meinem System zu folgenden Werten (mehrfach ausgeführt; war in etwa immer auf dem Niveau):ewx hat geschrieben:Ich habe in den zweiten READ auch eine Exception eingebaut. Das ändert nichts (messbares) an der Laufzeit.
Code: Alles auswählen.
1: 87
2: 11
3: 1Richtig. Je nach Anwendung kann es völlig bedeutungslos oder sehr erheblich sein, dass Anweisungen das Siebenfache der Laufzeit benötigen. Ich wollte ja nur darauf hinweisen, dass es diesen u.U. ganz erheblichen Preis gibt.Ralf hat geschrieben:Zumal mich überhaupt nicht wundert, wenn OO-Coding grundsätzlich mehr Performance braucht, es gibt ja einen entsprechenden Overhead. Ich gehe deshalb auch davon aus, dass mehr Speicher benötigt wird.
Ich habe noch nie wen behaupten hören, dass dem nicht so ist. Der Schwerpunkt bei OO ist ja ein anderer. Würden wir den Fokus nur auf die Laufzeit setzen, müssten wir in Assembler programmieren und hätten erheblich mehr Aufwände.
Das ist richtig und doch nur die halbe Wahrheit, denn dass eine Tabellenzeile, die man zu lesen versucht, nicht existiert, ist in vielen realen Programmen mitnichten ein "absoluter Fehlerfall".adt hat geschrieben:Warum das TRY...CATCH-Beispiel soviel mehr an Laufzeit braucht ist rasch erklärt:
Es handelt sich um eine Ausnahme und da muss der Kernel die aktuelle Verarbeitung unterbrechen, alle Informationen (Speicherabbild usw.) sammeln und eine teure "Sprung"-Operation zum CATCH-Block durchführen.
Deswegen nimmt man so ein Konstrukt ja auch nicht für den Standardanwendungfall (hier "Prüfen ob vorhanden") sondern für den absoluten Fehlerfall, wo man nicht mehr anders kann als den Programmabschnitt zu verlassen.
Genau dafür hat die SAP ja auch den LINE_EXISTS eingeführt, dass eben KEINE Exception ausgelöst wird.
Der Charme der 7.40-Syntax liegt darin, den sperrigen READ TABLE nicht mehr zu benötigen:
meinetabelle[ spalte1 = 'x' ]
ist einfach viel schöner als
READ TABLE meinetabelle INTO wa_meinetabelle WITH KEY spalte1 = 'x' und benötigt auch weder eine Workarea noch ein Feldsymbol zur Aufnahme des Ergebnisses. Von den ergänzenden Möglichkeiten, das Ganze in umfangreicheren Ausdrücken einzubetten, ganz zu schweigen. In den meisten Fällen kann aber nicht ausgeschlossen werden, dass die Tabellenzeile nicht existiert, auch wenn das nicht ausschließlicher Gegenstand der Prüfung ist, ein LINE_EXISTS also nicht ausreicht. Deshalb muss man praktisch immer, wenn man die erstere der beiden o.g. Syntaxen verwendet, den sperrigen TRY-CATCH-ENDTRY-Block drumrumpacken.
Dadurch sieht die Sache nicht mehr so elegant aus, allerdings kann man argumentieren, dass dieser Block den auch nicht hübscheren IF SY-SUBRC <> 0...ENDIF-Block ersetzt, den man üblicherweise hinter einen READ TABLE-Befehl packt, so dass man an dieser Stelle nichts gewinnt und nichts verliert, wohl aber den Vorteil der schöneren Syntax bei der Tabellensuchzeile selber hat.
Wenn man aber für den Fall, dass die Tabellenzeile nicht existiert, das Siebenfache der Laufzeit draufzahlt, dann kann das je nach Programm ein ganz gewichtiger Faktor sein, jedenfalls dann, wenn man nicht davon ausgehen kann, dass die Zeile nur in seltenen Ausnahmefällen nicht existieren wird.
Als Ausweg bleibt der Umweg über den ASSIGN, mit dem man dann freilich doch wieder ein Workarea-Feldsymbol braucht. Blöd besonders dann, wenn man eh schon ein Zielfeld hat, in das man den Wert haben möchte, weil dann da nämlich
ASSIGN meinetabelle[ spalte1 = 'x' ] TO FIELD-SYMBOL(<meinetabelle>).
IF SY-SUBRC <> 0.
blah.
ENDIF.
zielfeld = <meinetabelle>.
steht, was ich kosmetisch für schlechter halte als
TRY.
zielfeld = meinetabelle[ spalte1 = 'x' ].
CATCH CX_SY_ITAB_LINE_NOT_FOUND. blah.
ENDTRY.
was aber im Falle des Nichtvorliegens der Tabellenzeile um fast eine Größenordnung schneller ist.
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Doch, natürlich reicht ein LINE_EXISTS - solange du nicht in der Bedingung einen weiteren Tabellenausdruck hast, der eigentlich einen eigenen LINE_EXISTS braucht. Das ist das, auf das ich immer wieder hingewiesen habe: In dem reklamierten Beispiel handelt es sich um einen Ausdruck mit ZWEI Tabellenausdrücken.
Die Ausnahme hat noch einen weiteren Vorteil: Man kann sie sehr gut zum Aufrufer hochreichen und so ein kaskasierendes Log aufbauen, das man im App-Log speichern kann. Das geht sonst nur recht umständlich.
Ralf
Die Ausnahme hat noch einen weiteren Vorteil: Man kann sie sehr gut zum Aufrufer hochreichen und so ein kaskasierendes Log aufbauen, das man im App-Log speichern kann. Das geht sonst nur recht umständlich.
Ralf
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 2029 / 274 /
426
)
»
Du bist im falschen Thread. Hier geht es um das vollwertige Lesen von Tabellenzeilen, nicht nur um deren Existenzprüfung.Doch, natürlich reicht ein LINE_EXISTS - solange du nicht in der Bedingung einen weiteren Tabellenausdruck hast, der eigentlich einen eigenen LINE_EXISTS braucht.
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Nein, bin ich nicht, weil es ja um die (Verhinderung der) Ausnahme geht, dass die zu lesende Zeile nicht existiert. Das geht mit LINE_EXISTS ganz hervorragend.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 2029 / 274 /
426
)
»
Ich soll einen LINE_EXISTS machen, ob die Zeile existiert, und dann die Zeile mit der 7.40-Syntax lesen? Das bedeutet, dass ich zweimal hintereinander die gleiche Suche ausführe (wovon übrigens auch die SAP ausdrücklich abrät, aus offensichtlichen Gründen) und auch der Code lang und hässlich wird. Da ist ja sogar der READ TABLE optisch ansprechender. Von allen Lösungen ist das die schlechteste.
Wenn wir einer Partei die Regierungsbeteiligung verweigern, die von einer Mehrheit gewählt worden ist, weil wir diese Partei für schlecht halten, da wir einer anderen Partei angehören, wie ist dann unsere eigene demokratische Gesinnung zu bewerten?
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Nö, sollst du nicht - aber du willst ja die Ausnahme umschiffen. Eine Idee, auf die ich nie kommen würde, weil ich Ausnahmen sehr nützlich finde. Ich hab schon sehr komplexe Anwendungen gesehen, die trotz Ausnahmeklassen sehr performant liefen.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 4011 / 209 /
283
)
»
Dann hab ich das falsch verstanden - was ist dann der Performancefresser?
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development -- 25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Bleibt nur noch der "READ" Befehl selber.
Vergleichbare Themen
3
Antw.
Antw.
3557
Views
Views
3
Antw.
Antw.
3968
Views
Views
3
Antw.
Antw.
2953
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Wo kann ich die Farbe von *-Zeilen in Eclipse einstellen?
vor einer Woche von DeathAndPain 14 / 101401
vor einer Woche von DeathAndPain 14 / 101401
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor einer Woche von JanR 1 / 6282
vor einer Woche von JanR 1 / 6282
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Wo kann ich die Farbe von *-Zeilen in Eclipse einstellen?
vor einer Woche von DeathAndPain 14 / 101401
vor einer Woche von DeathAndPain 14 / 101401
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor einer Woche von JanR 1 / 6282
vor einer Woche von JanR 1 / 6282
Unbeantwortete Forenbeiträge
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor einer Woche von JanR 1 / 6282
vor einer Woche von JanR 1 / 6282
F6862 - Stücklistenpositionen Massenhinzufügen ohne Änderungsnummer
April 2026 von Radinator 1 / 66451
April 2026 von Radinator 1 / 66451
HR Forms (SAP HCM): Anwenderdokumentation, Anleitung oder Schulungsunterlagen gesucht
April 2026 von PatHei 1 / 37600
April 2026 von PatHei 1 / 37600