Forms und feldsymbole
Das mag bei kleinen Tabellen in Ordnung sein. Bei großen Datenmengen ist ein LOOP mit CHECK im LOOP denkbar ungünstig.black_adept hat geschrieben:Hi RIG,
in einem soooooo einfachen Fall kannst du dann natürlich auch 1 Form für beides nehmen: Ich gebe dir aber nur ein Outline - du sollst schon selber noch ein wenig rumfrickeln. Das bringt dir letztlich mehr.
1.) Übergabe der Tabelle (generisch) und des Suchwertes ( am besten Typisiert ).
2.) Loop ... Assigning in ein generisches Feldsymbol ( das dann zur Laufzeit deiner Tabellenzeile entspricht ).
3.) Innerhalb des Loop machst du ein MOVE-CORRESPONDING in eine typisierte Struktur, die mindestens das Feld enthält, welches du auswerten möchtest.
4.) Test der typisierten Struktur ob der Suchwert erfüllt ist. Falls ja: zählen
Da fand ich meine Idee besser...!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
hi!
MOVE-CORRESPONDING überträgt dann aus dem untypisierten Feldsymbol nur jene Felder die dort auch enthalten sind.
Du musst also nur noch überlegen wie die Abfrage im Loop mit Leerwerten umgeht. Denn entweder war dann das Feld nicht in der übergebenen Tabelle oder aber es war tatsächlich nicht befüllt.
lg ADT
RIG hat geschrieben:Genau da steh ich ja wieder vor meinem Problem mit dem Feldsymbol in meiner Form. Wenn es erst zur Laufzeit zugewiesen werden soll und ich es nicht übergeben darf hab ich noch keinen geschmeidigen Einfall.
Gemeint ist, dass du innerhalb deiner Form-Routine eine Struktur anlegst die, die Felder aus BEIDEN Tabellen beinhaltet und für die Abfrage notwendig sind.black_adept hat geschrieben:Definier das FS vom Type ANY. Dann bekommt es automatisch beim LOOP AT...ASSIGNING den korrekten Type zugewiesen.
MOVE-CORRESPONDING überträgt dann aus dem untypisierten Feldsymbol nur jene Felder die dort auch enthalten sind.
Du musst also nur noch überlegen wie die Abfrage im Loop mit Leerwerten umgeht. Denn entweder war dann das Feld nicht in der übergebenen Tabelle oder aber es war tatsächlich nicht befüllt.
lg ADT
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
Super - jetzt hat es geklappt und es gefällt mir sogar 
Vielen Dank
Vielen Dank an alle, Ihr seit alle eine riesige Hilfe für Abap-Neulinge wie mich.
VG Rig
Code: Alles auswählen.
Sort gt_cars_bookrent by rentclass.
Sort gt_sched_bookrent by rentclass.
gv_class_want = 'KOMPAKTKLASSE'.
Perform CountGroupLinesTEST Using gt_cars_bookrent
gv_class_want
Changing gv_Lange.
gv_Lange = 0.
Perform CountGroupLinesTEST Using gt_sched_bookrent
gv_class_want
Changing gv_Lange.
form COUNTGROUPLINESTEST using ut_grouped_Table type any table
uv_class_want type zrig_rentclass
changing cv_lange type i.
Data: ls_rentclass type ts_rentclass.
FIELD-SYMBOLS: <ls_FIELDSYMBOL> type any.
LOOP AT ut_grouped_Table ASSIGNING <ls_FIELDSYMBOL>.
MOVE-CORRESPONDING <ls_FIELDSYMBOL> to ls_rentclass.
IF ls_rentclass-rentclass = uv_class_want.
cv_lange = cv_lange + 1.
ENDIF.
IF ls_rentclass-rentclass <> uv_class_want AND cv_Lange > 0.
Exit.
ENDIF.
ENDLOOP.
endform. " COUNTGROUPLINESTEST
Das Makro sieht auch schick aus, da ich aber in mehreren Forms und includes auf die Funktion zugreifen möchte und das dann wiederrum seine Tücken hat habe ich mich für die Variante mit forms und fs entschieden.ewx hat geschrieben:ja, z.B. so:
Alternative wäre ein Makro:Aufruf der Makros:Code: Alles auswählen.
define count_entries. loop at &1 transporting no fields where &2 = &3. add 1 to &4. endloop. end-of-definition.& ist das "kaufm. UND"...!Code: Alles auswählen.
count_entries gt_cars aa '2' count1. count_entries gt_sched aa '2' count2.
Vielen Dank an alle, Ihr seit alle eine riesige Hilfe für Abap-Neulinge wie mich.
VG Rig
ewx hat geschrieben:Das mag bei kleinen Tabellen in Ordnung sein. Bei großen Datenmengen ist ein LOOP mit CHECK im LOOP denkbar ungünstig.black_adept hat geschrieben:Hi RIG,
in einem soooooo einfachen Fall kannst du dann natürlich auch 1 Form für beides nehmen: Ich gebe dir aber nur ein Outline - du sollst schon selber noch ein wenig rumfrickeln. Das bringt dir letztlich mehr.
1.) Übergabe der Tabelle (generisch) und des Suchwertes ( am besten Typisiert ).
2.) Loop ... Assigning in ein generisches Feldsymbol ( das dann zur Laufzeit deiner Tabellenzeile entspricht ).
3.) Innerhalb des Loop machst du ein MOVE-CORRESPONDING in eine typisierte Struktur, die mindestens das Feld enthält, welches du auswerten möchtest.
4.) Test der typisierten Struktur ob der Suchwert erfüllt ist. Falls ja: zählen
Da fand ich meine Idee besser...!
Meine Tabellen sind nicht so groß. Aber für den Fall das sie groß wären, welche Deiner Methoden ist denn dann besser - Makro oder Variante 1?
Wäre mal auszutesten.RIG hat geschrieben:Meine Tabellen sind nicht so groß. Aber für den Fall das sie groß wären, welche Deiner Methoden ist denn dann besser - Makro oder Variante 1?
Wenn man bei Variante 1 noch den READ-Zusatz BINARY SEARCH verwendet oder entsprechend definierte Tabellen würde ich glatt darauf tippen, dass die READ-Variante (1) schneller ist als der LOOP WHERE.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Hi ewx,ewx hat geschrieben: Das mag bei kleinen Tabellen in Ordnung sein. Bei großen Datenmengen ist ein LOOP mit CHECK im LOOP denkbar ungünstig.
irgendwie kann ich das nicht glauben. Könntest du mal erläutern warum das so sein soll?
Das inperformanteste bei "meiner" Methode ist das MOVE-CORRESPONDING innerhalb des LOOP. Aber selbst das könnte man durch performantere - aber m.E. schlechter lesbarere - Methodik austauschen. Und deine Kritik ist ja auch nicht an diesem Befehl aufgehängt sondern an dem LOOP + CHECK.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Hallo RIG,RIG hat geschrieben:Code: Alles auswählen.
... IF ls_rentclass-rentclass <> uv_class_want AND cv_Lange > 0. Exit. ENDIF. ...
ich finde deine Abbruchbedingung recht einfallsreich.
Aber aus demselben Grund aus dem ich ewx schon gerade gefragt habe warum er den LOOP+CHECK suboptimal findet, würde ich dir dazu raten die beiden SORT-Befehle und diese Abbruchbedingung wegzulassen.
Kannst Du mir auch sagen warum? Für den Fall das jemand eine unsortierte Tabelle reinschiebt?black_adept hat geschrieben:Hallo RIG,RIG hat geschrieben:Code: Alles auswählen.
... IF ls_rentclass-rentclass <> uv_class_want AND cv_Lange > 0. Exit. ENDIF. ...
ich finde deine Abbruchbedingung recht einfallsreich.
Aber aus demselben Grund aus dem ich ewx schon gerade gefragt habe warum er den LOOP+CHECK suboptimal findet, würde ich dir dazu raten die beiden SORT-Befehle und diese Abbruchbedingung wegzulassen.
Sorten muss ich sowieso, da ich kurz darauf Gruppenstufen in Loops verwende.
Vg RiG
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Hi RIG,
wenn du die Tabellen sowieso sortieren musst, ist deine Lösung klasse. Aber der Zeitaufwand für Sortieren + Abbruchbedingung wäre größer gewesen als beides wegzulassen.
Ist allerdings noch effektiver.
wenn du die Tabellen sowieso sortieren musst, ist deine Lösung klasse. Aber der Zeitaufwand für Sortieren + Abbruchbedingung wäre größer gewesen als beides wegzulassen.
Code: Alles auswählen.
IF ls_rentclass-rentclass > uv_class_want.
Exit.
ENDIF.Genau, weil bei einem Loop über eine Tabelle mit hundert Tausenden von Einträgen jeden Eintrag durchläuft und ein Assign und ein Check macht. Da ist doch ein READ schneller, oder nicht?black_adept hat geschrieben:Hi ewx,ewx hat geschrieben: Das mag bei kleinen Tabellen in Ordnung sein. Bei großen Datenmengen ist ein LOOP mit CHECK im LOOP denkbar ungünstig.
irgendwie kann ich das nicht glauben. Könntest du mal erläutern warum das so sein soll?
Das inperformanteste bei "meiner" Methode ist das MOVE-CORRESPONDING innerhalb des LOOP. Aber selbst das könnte man durch performantere - aber m.E. schlechter lesbarere - Methodik austauschen. Und deine Kritik ist ja auch nicht an diesem Befehl aufgehängt sondern an dem LOOP + CHECK.
Oder habe ich an deinem Vorschlag was falsch verstanden?
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Hi Enno,
das Problem ist nicht der Loop selber sondern das vorherige Sortieren.
Nimm mal eine Tabelle mit n Zeilen.
Den Loop selber kannst du zeitmäßig durch O(n) nach oben abschätzen. Da ich MOVE-CORRESPONDING, ASSIGN und Vergleiche als konstante Laufzeitverbraucher ansehen ist somit der gesamte Loop von der Größenordnung O(n).
Das Sortieren hingegen (da eine allgemeine Routine auf nicht-nummerischen Daten) hat als untere Schranke im Laufzeitverbrauch o(n*log(n)) ( Siehe Wikipedia )
--> Für n->unendlich ist das Sortieren die (zeit)verbrauchendste Operation und somit der Loop ohne vorherige Sortierung am günstigsten.
das Problem ist nicht der Loop selber sondern das vorherige Sortieren.
Nimm mal eine Tabelle mit n Zeilen.
Den Loop selber kannst du zeitmäßig durch O(n) nach oben abschätzen. Da ich MOVE-CORRESPONDING, ASSIGN und Vergleiche als konstante Laufzeitverbraucher ansehen ist somit der gesamte Loop von der Größenordnung O(n).
Das Sortieren hingegen (da eine allgemeine Routine auf nicht-nummerischen Daten) hat als untere Schranke im Laufzeitverbrauch o(n*log(n)) ( Siehe Wikipedia )
--> Für n->unendlich ist das Sortieren die (zeit)verbrauchendste Operation und somit der Loop ohne vorherige Sortierung am günstigsten.
Okay. Das war die Theorie...
Hier kommt der Praxistest für beide Varianten (LOOP du, READ ich):
Ich hatte keine Lust, den Test weiter für Millionen von Datensätzen zu machen.
Nachdem ich hiermit eindeutig recht habe, reicht mir der Test auch! *GGG*
Mag sein, dass deine Routine bei 2,3 mio Datensätzen wieder schneller funktioniert...
Achja: Hier noch das Programm:
Hier kommt der Praxistest für beide Varianten (LOOP du, READ ich):
Code: Alles auswählen.
Durchlauf Sätze "LOOP" "READ"
1 13.680 40.833 27.835
2 27.360 82.722 40.287
3 41.040 120.952 60.993
4 54.720 159.002 82.381
5 68.400 195.908 108.358
6 82.080 256.552 130.982
7 95.760 268.023 145.924
8 109.440 343.610 170.576
9 123.120 329.162 199.473
10 136.800 367.587 208.661
11 150.480 400.678 249.956
12 164.160 445.614 274.626
13 177.840 469.790 277.409
14 191.520 535.171 312.353
15 205.200 599.543 346.641
16 218.880 615.087 356.632
17 232.560 644.617 383.314
18 246.240 743.851 400.060
19 259.920 674.811 482.823
20 273.600 706.703 380.553
21 287.280 733.762 490.509
22 300.960 787.191 278.219
23 314.640 816.793 276.794
24 328.320 763.948 351.221
25 342.000 880.663 410.866
Nachdem ich hiermit eindeutig recht habe, reicht mir der Test auch! *GGG*
Mag sein, dass deine Routine bei 2,3 mio Datensätzen wieder schneller funktioniert...
Achja: Hier noch das Programm:
Code: Alles auswählen.
DATA gt_mara TYPE STANDARD TABLE OF mara WITH NON-UNIQUE DEFAULT KEY.
DATA gt_mara1 TYPE STANDARD TABLE OF mara WITH NON-UNIQUE DEFAULT KEY.
FIELD-SYMBOLS <mara> TYPE ANY.
FIELD-SYMBOLS <value> TYPE ANY.
DATA start TYPE i.
DATA stopp TYPE i.
DATA diff TYPE i.
DATA index TYPE i.
PARAMETERS p_ernam TYPE ernam DEFAULT 'ENNO'.
PARAMETERS p_var TYPE n LENGTH 1 DEFAULT '1'.
PARAMETERS p_anz type i DEFAULT 25.
START-OF-SELECTION.
SELECT * FROM mara INTO TABLE gt_mara1.
WRITE: 'VARIANTE', p_var.
ULINE.
DO p_anz TIMES.
WRITE: / 'Druchlauf:', sy-index.
APPEND LINES OF gt_mara1 TO gt_mara.
sy-dbcnt = LINES( gt_mara ).
WRITE: sy-dbcnt.
CLEAR sy-dbcnt.
GET RUN TIME FIELD start.
CASE p_var.
WHEN '1'.
LOOP AT gt_mara ASSIGNING <mara>.
ASSIGN COMPONENT 'ERNAM' OF STRUCTURE <mara> TO <value>.
CHECK <value> = p_ernam.
ADD 1 TO sy-dbcnt.
ENDLOOP.
WHEN '2'.
SORT gt_mara BY ernam.
READ TABLE gt_mara ASSIGNING <mara> WITH KEY ('ERNAM') = p_ernam BINARY SEARCH.
IF sy-subrc = 0.
ADD 1 TO sy-dbcnt.
index = sy-tabix + 1.
DO.
READ TABLE gt_mara ASSIGNING <mara> INDEX index.
ASSIGN COMPONENT 'ERNAM' OF STRUCTURE <mara> TO <value>.
IF <value> = p_ernam.
ADD 1 TO sy-dbcnt.
ADD 1 TO index.
ELSE.
EXIT. "from do.
ENDIF.
ENDDO.
ENDIF.
ENDCASE.
GET RUN TIME FIELD stopp.
diff = stopp - start.
WRITE: diff.
ENDDO.
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
*räusper* - die rot markierten Zeilen machen mich doch arg stutzig ob der Aussagekraft dieser Auswertung.ewx hat geschrieben: Durchlauf Sätze "LOOP" "READ"
19 259.920 674.811 482.823
20 273.600 706.703 380.553
21 287.280 733.762 490.509
22 300.960 787.191 278.219
23 314.640 816.793 276.794
24 328.320 763.948 351.221
25 342.000 880.663 410.866
Aber du hast natürlich insofern recht, dass der konstante Faktor in O(n) recht groß sein kann, so dass "deine" Version für hinreichend kleine Werte tatsächlich schneller ist.
Was zeigt uns das? Am Besten ist es einfach auszuprobieren was schneller ist, wie groß der Zeitgewinn ist und ob das den Lesbarkeitsverlust ausgleicht. ( 5 Zeilen Coding vs. 16 Zeilen )
Ich habe keine Doktorarbeit draus gemacht, das ist war...
Aber die Tendenz war recht deutlich.
Aber die Tendenz war recht deutlich.
Kommt dann darauf an, ob man das Programm öfter ausführt, als man es liest, oder umgekehrt...black_adept hat geschrieben:Was zeigt uns das? Am Besten ist es einfach auszuprobieren was schneller ist, wie groß der Zeitgewinn ist und ob das den Lesbarkeitsverlust ausgleicht. ( 5 Zeilen Coding vs. 16 Zeilen )
Vergleichbare Themen
2
Antw.
Antw.
1513
Views
Views
0
Antw.
Antw.
1001
Views
Views
4
Antw.
Antw.
2371
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.