INTO CORRESPONDING FIELDS OF TABLE VS. INtO TABLE
Moin.
Also nachdem ich das ganze Grundrauschen rausgefiltert habe, sehe ich 3 Kritikpunkte, die du mir gegenüber anbringst:
1. Ich empfehle HASHED TABLEs statt SORTED
Wusste gar nicht, dass O(1) langsamer ist als O(log(n))
. Ich würde echt gerne den Tread sehen bei denen du den Vergleich gemacht hast. Würde mich ernsthaft interessieren.
Ich habe auch mal ein Testprogramm geschrieben mit einem gar nicht mal so abwegigen Use-Case: Lese Daten aus der DB in eine HASHED oder SORTED Tabelle und greife in einem LOOP darauf zu.
Also sowohl bei wenigen Datensätzen (100) als auch bei mittlerer Anzahl (5000) als auch bei großer Anzahl von (1000000) ist die HASEHD Tabelle sowohl im befüllen der Tabelle, also der Schlüssel-Generierung, als auch beim Lesen deutlich schneller.
Hier der Code. Ich denke, dass der Test fair ist:
Zu 2.:
ich sagte, dass die Tabelle T002 vollständig gepuffert ist. Habe versucht implizit darauf hinzuweisen, dass die Messung Schwachstellen hat. Habe wohl etwas zu viel Transferleistung erwartet. Den Vorwurf, nicht komplett alle Fakten und Hintergründe haarklein zu beschreiben, lasse ich gelten. Werde versuchen mich deutlicher und umfassender auszudrücken.
Zu 3.:
Ändert aber nichts an der Tatsache, dass keine Indizes drauf sind. Egal ob Cluster oder Transparent.
Was ich mitnehme: Ich muss mich besser und ausführlicher Ausdrücken, um Missverständnisse zu vermeiden. Danke, dass du mich implizit drauf hingewiesen hast.
PS:
Deine Ausführungen Bright4.5 gegenüber mit dem schwachen JOIN finde ich gut!
Also nachdem ich das ganze Grundrauschen rausgefiltert habe, sehe ich 3 Kritikpunkte, die du mir gegenüber anbringst:
1. Ich empfehle HASHED TABLEs statt SORTED
2. Ich sage, dass die Tabellen gepuffert werdenDeathAndPain hat geschrieben:nickname8, Du solltest Deine Überzeugungen unbedingt sorgsamer mit der Realität abgleichen, bevor Du sie im Brustton der Überzeugung vorträgst. Was Du hier alles an zweifelhaften Behauptungen aufgestellt hast, geht auf keine Kuhhaut. Damit verunsicherst Du andere Anwender und schickst sie auf falsche Gleise.
Ich habe auch mal geglaubt, dass hashed-Tabellen besser seien. Bis ich mir irgendwann mal die Mühe gemacht habe, ein Testprogramm zu schreiben und die Performance zu messen. (Irgendwo hier gibt es noch den Thread, in dem ich das Programm und meine Messergebnisse vorgestellt habe.) Das Ergebnis war, dass das Füllen der Hashtabelle (wohl wegen der Berechnung der Hashes) um so viel langsamer war, dass man hinterher Abertausende von Suchvorgängen brauchen würde, damit sich dieser Nachteil gegenüber einer sorted table amortisiert. Dabei nützt es auch nichts, von besonders großen Tabellen auszugehen. Bei denen ist der (geringe) Suchvorteil der hashed table zwar größer, dafür sind aber auch entsprechend mehr Hashes beim Befüllen der Tabelle zu berechnen.nickname8 hat geschrieben:- sortierte oder noch besser hashed tabellen nutzen
3. Ich sage, dass die REGUP eine Clustertabelle istDeathAndPain hat geschrieben:Die ABAP-Tabellenpufferung hat damit gar nichts zu tun, die ist nämlich nur bei Tabellen überschaubarer Größe (typischerweise Customizingtabellen) aktiviert, nicht bei den Anwendungsdatentabellen, auf die man in seinen Programmen meist zugreift. Der hier beschriebene Effekt tritt jedoch auch bei letzteren auf. Ursache ist, dass die Datenbanken selber auch puffern. Wer oft hintereinander auf dieselbe Tabelle oder gar dieselben Sätze der Tabelle zugreift, bekommt die späteren Zugriffe wesentlich schneller erledigt. Das ist nicht so schnell wie die ABAP-Tabellenpufferung, die SAP-serverseitig im Hauptspeicher erfolgt und schon gar nicht so schnell wie eine durchdacht programmierte Pufferung in einer sortierten internen Tabelle, aber es ist allemal drastisch schneller als ein erstmaliger Zugriff.nickname8 hat geschrieben:Wird es.Tommy hat geschrieben:anscheinend wird das irgendwie gepuffert...
https://ibb.co/HGR3XmF
Zu 1.:DeathAndPain hat geschrieben:Auf was für einem alten Release sitzt Du? Die SAP stellt Clustertabellen nach und nach auf transparente Tabellen um, und auf meinem 7.50 ist die REGUP auch eine transparente Tabelle. Weitere Indizes sind trotzdem nicht darauf definiert, aber das könnte man notfalls selber machen. Sollte man natürlich möglichst vermeiden, weil es bei großen Tabelle viel Speicherplatz und auch etwas Rechenzeit kostet.nickname8 hat geschrieben:- REGUP ist eine Clustertabelle - da gibts keine zusätzlichen Indizes drauf
Wusste gar nicht, dass O(1) langsamer ist als O(log(n))
. Ich würde echt gerne den Tread sehen bei denen du den Vergleich gemacht hast. Würde mich ernsthaft interessieren.Ich habe auch mal ein Testprogramm geschrieben mit einem gar nicht mal so abwegigen Use-Case: Lese Daten aus der DB in eine HASHED oder SORTED Tabelle und greife in einem LOOP darauf zu.
Also sowohl bei wenigen Datensätzen (100) als auch bei mittlerer Anzahl (5000) als auch bei großer Anzahl von (1000000) ist die HASEHD Tabelle sowohl im befüllen der Tabelle, also der Schlüssel-Generierung, als auch beim Lesen deutlich schneller.
Hier der Code. Ich denke, dass der Test fair ist:
Code: Alles auswählen.
INITIALIZATION.
PARAMETERS: p_rows TYPE i.
START-OF-SELECTION.
TYPES:
BEGIN OF t_key,
tabname TYPE dd03l-tabname,
fieldname TYPE dd03l-fieldname,
as4local TYPE dd03l-as4local,
as4vers TYPE dd03l-as4vers,
position TYPE dd03l-position,
END OF t_key.
DATA lt_dd03l_hashed TYPE HASHED TABLE OF dd03l WITH UNIQUE KEY tabname fieldname as4local as4vers position.
DATA lt_dd03l_sorted TYPE SORTED TABLE OF dd03l WITH NON-UNIQUE KEY tabname fieldname as4local as4vers position.
DATA ls_dd03l TYPE dd03l.
DATA lv_int TYPE i.
DATA lt_key TYPE TABLE OF t_key.
DATA ls_key TYPE t_key.
SELECT * UP TO @p_rows ROWS
FROM dd03l
INTO TABLE @DATA(lt_dd03l).
DATA(lv_lines) = lines( lt_dd03l ).
lv_int = sy-timlo.
DATA(lo_ran) = cl_abap_random_int=>create( min = 1 max = lv_lines seed = lv_int ).
DO lv_lines TIMES.
CLEAR ls_key.
lv_int = lo_ran->get_next( ).
READ TABLE lt_dd03l INTO ls_dd03l INDEX lv_int.
ls_key-tabname = ls_dd03l-tabname.
ls_key-fieldname = ls_dd03l-fieldname.
ls_key-as4local = ls_dd03l-as4local.
ls_key-as4vers = ls_dd03l-as4vers.
ls_key-position = ls_dd03l-position.
APPEND ls_key TO lt_key.
ENDDO.
GET RUN TIME FIELD DATA(m0).
lt_dd03l_hashed = lt_dd03l.
GET RUN TIME FIELD DATA(m1).
LOOP AT lt_key ASSIGNING FIELD-SYMBOL(<fs>).
READ TABLE lt_dd03l_hashed WITH TABLE KEY tabname = <fs>-tabname
fieldname = <fs>-fieldname
as4local = <fs>-as4local
as4vers = <fs>-as4vers
position = <fs>-position
TRANSPORTING NO FIELDS.
ENDLOOP.
GET RUN TIME FIELD DATA(m2).
DATA(e0) = m1 - m0.
DATA(e1) = m2 - m1.
DATA(e5) = m2 - m0.
WRITE: 'Befüllen HASHED TABLE: ', e0.
WRITE: / 'READ HASHED TABLE: ', e1.
WRITE: / 'Gesamt HASHED TABLE: ', e5.
WRITE /.
GET RUN TIME FIELD DATA(m3).
lt_dd03l_sorted = lt_dd03l.
GET RUN TIME FIELD DATA(m4).
LOOP AT lt_key ASSIGNING <fs>.
READ TABLE lt_dd03l_sorted WITH TABLE KEY tabname = <fs>-tabname
fieldname = <fs>-fieldname
as4local = <fs>-as4local
as4vers = <fs>-as4vers
position = <fs>-position
TRANSPORTING NO FIELDS.
ENDLOOP.
GET RUN TIME FIELD DATA(m5).
DATA(e2) = m4 - m3.
DATA(e3) = m5 - m4.
DATA(e4) = m5 - m3.
WRITE: 'Befüllen SORTED TABLE: ', e2.
WRITE: / 'READ SORTED TABLE: ', e3.
WRITE: / 'Gesamt SORTED TABLE: ', e4.
ich sagte, dass die Tabelle T002 vollständig gepuffert ist. Habe versucht implizit darauf hinzuweisen, dass die Messung Schwachstellen hat. Habe wohl etwas zu viel Transferleistung erwartet. Den Vorwurf, nicht komplett alle Fakten und Hintergründe haarklein zu beschreiben, lasse ich gelten. Werde versuchen mich deutlicher und umfassender auszudrücken.
Zu 3.:
Alt. Zu alt.DeathAndPain hat geschrieben: Auf was für einem alten Release sitzt Du?
Wer weiß auf welchem Release Bright4.5 sitzt...DeathAndPain hat geschrieben:Die SAP stellt Clustertabellen nach und nach auf transparente Tabellen um, und auf meinem 7.50 ist die REGUP auch eine transparente Tabelle. Weitere Indizes sind trotzdem nicht darauf definiert, aber das könnte man notfalls selber machen. Sollte man natürlich möglichst vermeiden, weil es bei großen Tabelle viel Speicherplatz und auch etwas Rechenzeit kostet.
Ändert aber nichts an der Tatsache, dass keine Indizes drauf sind. Egal ob Cluster oder Transparent.
Was ich mitnehme: Ich muss mich besser und ausführlicher Ausdrücken, um Missverständnisse zu vermeiden. Danke, dass du mich implizit drauf hingewiesen hast.
PS:
Deine Ausführungen Bright4.5 gegenüber mit dem schwachen JOIN finde ich gut!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
@nickname8:
ad1 https://www.abapforum.com/forum/viewtop ... =1&t=22358
Desweiteren noch ein Kommentar zu folgendem:
Ich glaube, dass die meisten Leute vergessen, dass die zugehörigen Konstanten in den beiden Abschätzungen O(1) und O(log(n)) im Allgemeinen nicht gleich sind. Damit ist ja nur gesagt, dass für hinreichend große n der erste Ausdruck kleiner als der andere wird! Aber ab welchem n das gilt....?
Desweiteren betrifft die Abschätzung lediglich das Lesen aus einer Hash-Tabelle. Die Zeit, die lt. D&Ps Vergleich zum Aufbau der Hashtabelle bzw. sorted Tabelle verwendet wird ist dabei nicht berücksichtigt und ich habe leider auch gerade keine O-Abschätzungen für diesen Fall parat. Und letztlich setzt sich die Laufzeit ja aus Aufbau+Operationen auf der Tabelle zusammen, so dass das nicht losgelöst voneinander betrachtet werden sollte.
( P.S. Auch wenn ich hier D&Ps Argumentation nachvollziehen kann - ich persönlich verwende fast immer Hashtabellen wo es mir sinnvoll erscheint wobei ich mich dann immer wieder über mich selbst ärgere, wenn ich einen Loop über eine Hash-Tabelle mache um dann den Fehler machen den sy-tabix abzufragen )
@D&P:
ad 2) Tabellenpufferung: Gilt dies Aussage bzgl. nicht gepufferter Anwendungstabellen auch für In-Memory-Computing?
ad1 https://www.abapforum.com/forum/viewtop ... =1&t=22358
Desweiteren noch ein Kommentar zu folgendem:
Das wird ja immer als Argument verwendet um für Hash-Tabellen zu werben. Allerdings ist D&Ps Vergleich nicht von der Hand zu weisen.nickname8 hat geschrieben:Zu 1.:
Wusste gar nicht, dass O(1) langsamer ist als O(log(n))
Ich glaube, dass die meisten Leute vergessen, dass die zugehörigen Konstanten in den beiden Abschätzungen O(1) und O(log(n)) im Allgemeinen nicht gleich sind. Damit ist ja nur gesagt, dass für hinreichend große n der erste Ausdruck kleiner als der andere wird! Aber ab welchem n das gilt....?
Desweiteren betrifft die Abschätzung lediglich das Lesen aus einer Hash-Tabelle. Die Zeit, die lt. D&Ps Vergleich zum Aufbau der Hashtabelle bzw. sorted Tabelle verwendet wird ist dabei nicht berücksichtigt und ich habe leider auch gerade keine O-Abschätzungen für diesen Fall parat. Und letztlich setzt sich die Laufzeit ja aus Aufbau+Operationen auf der Tabelle zusammen, so dass das nicht losgelöst voneinander betrachtet werden sollte.
( P.S. Auch wenn ich hier D&Ps Argumentation nachvollziehen kann - ich persönlich verwende fast immer Hashtabellen wo es mir sinnvoll erscheint wobei ich mich dann immer wieder über mich selbst ärgere, wenn ich einen Loop über eine Hash-Tabelle mache um dann den Fehler machen den sy-tabix abzufragen )
@D&P:
ad 2) Tabellenpufferung: Gilt dies Aussage bzgl. nicht gepufferter Anwendungstabellen auch für In-Memory-Computing?
Danke für den Thread. Finde da aber nichts was mit sortierten und hashed Tabellen getestet wird. Es wird gesagt, dass die Suche in HASHED Tabellen nicht schneller geht als in sortierten. Da bin ich komplett auf eurer Seite. Beim Suchen hat man kein Vorteil ggü einer sortierten Tabelle. Aber beim finden mit einem kompletten Schlüssel ist eine Hashed Tabelle unschlagbar (außer die Tabelle hat 10 Zeilen). (10 sei jetzt hier einfach als kleine Datenmenge zu verstehen).
Im obigen Test habe ich ein n = 100 verwendet - und da hat es sich schon gelohnt. Ich habe auch die Generierung der Schlüssel gemessen. Die Hashes zu bilden ging schneller als den Index anzulegen bei der sortierten Tabelle.
Im obigen Test habe ich ein n = 100 verwendet - und da hat es sich schon gelohnt. Ich habe auch die Generierung der Schlüssel gemessen. Die Hashes zu bilden ging schneller als den Index anzulegen bei der sortierten Tabelle.
Also bei uns ist der Unterschied für die Praxis unbedeutend. Da kann man "anderswo" mehr sparen.
Bei dem Code unten erhalte ich mit den vor eingestellten Parametern folgendes Ergebnis:
0,0921730 hash build rtm
0,5758930 hash read rtm
0,1616500 sorted build rtm
0,8819710 sorted read rtm
Bei dem Code unten erhalte ich mit den vor eingestellten Parametern folgendes Ergebnis:
0,0921730 hash build rtm
0,5758930 hash read rtm
0,1616500 sorted build rtm
0,8819710 sorted read rtm
Code: Alles auswählen.
report.
parameters: p_rows type i default 100000.
parameters: p_doread type i default 5.
data: itkey type standard table of t100.
data: ithash type hashed table of t100 with unique key sprsl arbgb msgnr.
data: itsort type sorted table of t100 with unique key sprsl arbgb msgnr.
data: rtm_start type timestampl.
data: rtm_stop type timestampl.
data: rtm_diff type timestampl.
select * into table itkey from t100 up to p_rows rows.
"hash
get time stamp field rtm_start.
loop at itkey assigning field-symbol(<wakey>).
insert <wakey> into table ithash.
endloop.
get time stamp field rtm_stop.
compute rtm_diff = rtm_stop - rtm_start.
write: /01 rtm_diff, 'hash build rtm'.
rtm_start = rtm_stop.
do p_doread times.
loop at itkey assigning <wakey>.
read table ithash
assigning field-symbol(<wahash>)
with key sprsl = <wakey>-sprsl
arbgb = <wakey>-arbgb
msgnr = <wakey>-msgnr.
endloop.
enddo.
get time stamp field rtm_stop.
rtm_diff = rtm_stop - rtm_start.
write: /01 rtm_diff, 'hash read rtm'. uline.
"sorted
get time stamp field rtm_start.
loop at itkey assigning <wakey>.
insert <wakey> into table itsort.
endloop.
get time stamp field rtm_stop.
rtm_diff = rtm_stop - rtm_start.
write: /01 rtm_diff, 'sorted build rtm'.
rtm_start = rtm_stop.
do p_doread times.
loop at itkey assigning <wakey>.
read table itsort
assigning field-symbol(<wasorted>)
with key sprsl = <wakey>-sprsl
arbgb = <wakey>-arbgb
msgnr = <wakey>-msgnr.
endloop.
enddo.
get time stamp field rtm_stop.
compute rtm_diff = rtm_stop - rtm_start.
write: /01 rtm_diff, 'sorted read rtm'.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Womit wir wieder beim Thema "Theorie und Praxis" wären. Zum einen habe ich messen können, dass zumindest in der ABAP-Implementierung O(1) nicht hinhaut, denn bei sehr vielen Tabelleneinträgen maß ich auch bei Verwendung einer Hashtabelle eine längere Suchzeit als bei wenigen. Zum anderen hast Du aber den (schon von black_adept angeführten) Knackpunkt ignoriert, der zentraler Kernpunkt meiner Argumentation war: dass nämlich Hashtabellen (wie alle anderen auch) erst gefüllt werden müssen, bevor man sie benutzen kann. Und, um mich inhaltlich zu wiederholen: Dass Befüllen einer Hashtabelle dauert aufgrund der Notwendigkeit, für jede einzelne Zeile einen Hashwert zu berechnen, so viel länger als das Befüllen einer sortierten Tabelle, dass Du hinterher Abertausende von Suchvorgängen bräuchtest, um durch den geringen Suchzeitvorteil von Hashtabellen die ganze Zeit auszugleichen, die Du vorher beim Befüllen der Hashtabelle zusätzlich verbrannt hast! Nach meiner Praxiserfahrung kommt es so gut wie nie vor, dass man so oft in einer internen Tabelle suchen muss, dass man hier den Amortisationspunkt erreichen würde. Außer vielleicht wenn man schlampig programmiert und dieselbe Suche immer wiederholt, anstatt mit dem einmal gefundenen Ergebnis weiterzuarbeiten.nickname8 hat geschrieben:Zu 1.:
Wusste gar nicht, dass O(1) langsamer ist als O(log(n))
black_adept war so freundlich, einen Link zu dem Thread mit meinem Messprogramm zu bieten. In jenem Thread ging es aber nur um die ABAP Tabellenpufferung. Ich weiß, dass ich auch mal Messprogramme für den Vergleich STANDARD/SORTED/HASHED geschrieben und hier gepostet habe. Darin habe ich aber explizit auch die Befüllzeit gemessen und ausgegeben. Genau das tust Du in Deinem Code, den Du hier geboten hast, jedoch nicht, weswegen dieser völlig an meiner Argumentation vorbeigeht.
Und das ist eben das, was ich Dir die ganze Zeit vorwerfe: Du bist nicht sorgfältig genug, und zwar nicht nur in der Art und Weise, wie Du Dich ausdrückst, sondern auch inhaltlich. Und das schlägt sich leider in falschen Schlussfolgerungen nieder, die Du im weiteren Verlauf als Tatsache postulierst.
Nein. Du hast die T002 überhaupt nicht erwähnt, sondern nur auf einen Screenshot von ihr verlinkt. Und dazu hast Du gesagt, dass die Daten, um die es hier im Thread gehen würde, die nicht aus der T002 stammen und die mit hoher Wahrscheinlichkeit aus einer nicht im ABAP gepufferten Tabelle stammen, auf diese Weise gepuffert werden würden:nickname8 hat geschrieben:Zu 2.:
ich sagte, dass die Tabelle T002 vollständig gepuffert ist.
Immerhin bedeutet es, dass man die Chance hat, sich selber einen Index draufzulegen, wenn man für seine Kundenanwendungen einen benötigt. Ist formal gesehen zwar eine Modifikation, aber eine der harmlosesten Sorte (auch wenn nicht völlig auszuschließen ist, dass innerhalb des SAP-Standardcodes der Datenbankoptimierer eine schlechte Wahl trifft und den kundeneigenen Index wählt, obgleich an der Stelle der Standardindex besser wäre, so dass im Standard die Performance plötzlich schlechter wäre. Dazu müsste man aber das ganz große Los ziehen; das ist extrem unwahrscheinlich. Besonders dann, wenn man sich bei der Auswahl jenes Indexes Gedanken macht, statt da inkompetent wahllos irgendwelche Felder reinzuschreiben).nickname8 hat geschrieben:Wer weiß auf welchem Release Bright4.5 sitzt...
Ändert aber nichts an der Tatsache, dass keine Indizes drauf sind. Egal ob Cluster oder Transparent.
Auf der anderen Seite sollte man natürlich immer gute Gründe haben, weshalb man bei SAP-Tabellen mit den Indizes der SAP nicht auskommt. Unter Release 3.1i habe ich das noch relativ häufig erlebt; heutzutage hingegen so gut wie gar nicht mehr.
Damit quälst Du Dich selber aber ohne Not doppelt: Du hast die schlechtere Gesamtperformance und zudem den verringerten Programmierkomfort, weil Du die Option, mit Tabellenindex auf die Tabelle zuzugreifen, herschenkst. Wenn man das nicht braucht und im Gegenzug bessere Performance dafür kriegen würde, würde ich einen Sinn darin sehen, so aber ist es ein loss/loss-Szenario.black_adept hat geschrieben:( P.S. Auch wenn ich hier D&Ps Argumentation nachvollziehen kann - ich persönlich verwende fast immer Hashtabellen wo es mir sinnvoll erscheint wobei ich mich dann immer wieder über mich selbst ärgere, wenn ich einen Loop über eine Hash-Tabelle mache um dann den Fehler machen den sy-tabix abzufragen )
Wenn Du von S/4 HANA redest: Das gibt es für HCM leider noch nicht (kommt aber). Insofern kann ich dazu noch keine Aussage machen. Ich habe mich nur auf interne Tabellen bezogen, vermute aber, dass es für diese auch in S/4 gelten wird, da diese so oder so im Hauptspeicher liegen.black_adept hat geschrieben:@D&P:
ad 2) Tabellenpufferung: Gilt dies Aussage bzgl. nicht gepufferter Anwendungstabellen auch für In-Memory-Computing?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Legxis
Ich habe die T002 nicht erwähnt, aber Tommy Nightmare hat es gemacht. In seinem Beispielcoding. Sorry, ich war so naiv zu glauben, dass man sich den kompletten Thread durchliest und nicht nur einzelne Beiträge. Ich denke, dass der Kontext schon wichtig ist...DeathAndPain hat geschrieben: Nein. Du hast die T002 überhaupt nicht erwähnt, sondern nur auf einen Screenshot von ihr verlinkt. Und dazu hast Du gesagt, dass die Daten, um die es hier im Thread gehen würde, die nicht aus der T002 stammen und die mit hoher Wahrscheinlichkeit aus einer nicht im ABAP gepufferten Tabelle stammen, auf diese Weise gepuffert werden würden:
Hast du dafür auch ein Beispielcoding? Wie du meinem Beispielcoding entnehmen kannst, habe ich einen Gegenbeispiel mit dem Erstellen der HASH-Tabelle geliefert.DeathAndPain hat geschrieben:Womit wir wieder beim Thema "Theorie und Praxis" wären. Zum einen habe ich messen können, dass zumindest in der ABAP-Implementierung O(1) nicht hinhaut, denn bei sehr vielen Tabelleneinträgen maß ich auch bei Verwendung einer Hashtabelle eine längere Suchzeit als bei wenigen. Zum anderen hast Du aber den (schon von black_adept angeführten) Knackpunkt ignoriert, der zentraler Kernpunkt meiner Argumentation war: dass nämlich Hashtabellen (wie alle anderen auch) erst gefüllt werden müssen, bevor man sie benutzen kann. Und, um mich inhaltlich zu wiederholen: Dass Befüllen einer Hashtabelle dauert aufgrund der Notwendigkeit, für jede einzelne Zeile einen Hashwert zu berechnen, so viel länger als das Befüllen einer sortierten Tabelle, dass Du hinterher Abertausende von Suchvorgängen bräuchtest, um durch den geringen Suchzeitvorteil von Hashtabellen die ganze Zeit auszugleichen, die Du vorher beim Befüllen der Hashtabelle zusätzlich verbrannt hast! Nach meiner Praxiserfahrung kommt es so gut wie nie vor, dass man so oft in einer internen Tabelle suchen muss, dass man hier den Amortisationspunkt erreichen würde. Außer vielleicht wenn man schlampig programmiert und dieselbe Suche immer wiederholt, anstatt mit dem einmal gefundenen Ergebnis weiterzuarbeiten.nickname8 hat geschrieben:Zu 1.:
Wusste gar nicht, dass O(1) langsamer ist als O(log(n))
Und damit will ich dich echt nicht triggern oder so, ich bin echt interessiert das zu analysieren.
Nachtrag: es geht mir bei HASHED-Tabelle natürlich immer nur um Zugriffe per WITH TABLE KEY, also mit dem kompletten Schlüssel.
@Dele: du hast ja get time stamp field benutzt, ist da ein wirklicher Unterschied zu GET RUN TIME FIELD?
Weil leider lässt sich es nicht wirklich messen, sondern ich muss einen Durchschnitt bilden.
Vermutlich nicht und eigentlich ist die Frage dumm, aber ich klammer mich noch an die Hoffnung, dass man es irgendwie besser messen kann
.
Weil leider lässt sich es nicht wirklich messen, sondern ich muss einen Durchschnitt bilden.
Vermutlich nicht und eigentlich ist die Frage dumm, aber ich klammer mich noch an die Hoffnung, dass man es irgendwie besser messen kann
.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
@D&P: Leider habe ich gesehen, dass du außer deiner Aussage, dass du mal Messungen gemacht hast keine belastbaren Codeschnipsel von dir gefunden. Und ich glaube, dass du auch nie welche geliefert hattest. Allerdings kann ich die Aussage, dass Hash-Tabellen zum Aufbau "viel länger" dauert als sortierte Tabellen bei eigenen Tests nicht nachvollziehen. Ja - dauert etwas länger - aber eben nicht viel.
@nickname8: Aber D&P hat mit seinem "Amortisationspunkt" ein gutes Argument. Du argumentierst mit den Landau-Symbolen bzw. dem dadurch dargestellten asymptotischen Verhalten für eine große Anzahl von Zugriffen - D&P hingegen redet von für seine Verhältnisse "üblichen" Zugriffszahlen (welche ich aus der Praxis grob teilen kann ). Und bei diesen Größenordnungen ist es tatsächlich so, dass der Zeitanteil für das Aufbauen der Hashtabelle ins Gewicht fällt.
@beide: Aber solange wir uns in SAP-typischen Größenordnungen bewegen mit "normalen" Zugriffszahen ist das alles Jacke wie Hose. Nehmt doch das was euch gefällt - den Unterschied wird kein Anwender oder ihr selber merken!
@nickname8: Aber D&P hat mit seinem "Amortisationspunkt" ein gutes Argument. Du argumentierst mit den Landau-Symbolen bzw. dem dadurch dargestellten asymptotischen Verhalten für eine große Anzahl von Zugriffen - D&P hingegen redet von für seine Verhältnisse "üblichen" Zugriffszahlen (welche ich aus der Praxis grob teilen kann ). Und bei diesen Größenordnungen ist es tatsächlich so, dass der Zeitanteil für das Aufbauen der Hashtabelle ins Gewicht fällt.
@beide: Aber solange wir uns in SAP-typischen Größenordnungen bewegen mit "normalen" Zugriffszahen ist das alles Jacke wie Hose. Nehmt doch das was euch gefällt - den Unterschied wird kein Anwender oder ihr selber merken!
Zum Thema Hash-Tabelle:
Ich bekomm hier immer die Fehlermeldung: "Auf Tabellen vom Typ "HASHED TABLE" bzw. "ANY TABLE" sind weder explizite noch implizite Indexoperationen erlaubt.
Liegt daran, dass ich noch den Sy-Tabix brauche. Ist das bei einer Hash-Tabelle irgendwie möglich ? Wenn diese Tabellenart überhaupt was bringt... ist ja hier noch nicht geklärt und ich hab mich mit Hash-Tabellen noch nie befasst.
Ich bekomm hier immer die Fehlermeldung: "Auf Tabellen vom Typ "HASHED TABLE" bzw. "ANY TABLE" sind weder explizite noch implizite Indexoperationen erlaubt.
Liegt daran, dass ich noch den Sy-Tabix brauche. Ist das bei einer Hash-Tabelle irgendwie möglich ? Wenn diese Tabellenart überhaupt was bringt... ist ja hier noch nicht geklärt
und ich hab mich mit Hash-Tabellen noch nie befasst.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
@nickname8: In Deinem Testprogramm schmeißt Du mit Inline-Datendeklarationen um Dich. Und da behauptest Du, auf einem alten Release zu sitzen?
Zufällig habe ich mein Testprogramm noch gefunden; glücklicherweise habe ich es noch nicht gelöscht. Wie gesagt, ich bin der Meinung, es schon mal gepostet zu haben, aber ich finde den damaligen Thread beim besten Willen nicht wieder.
Wie dem auch sein mag, hier ist es:
Da es komplett ohne Datenbank arbeitet und noch keine 7.40-Syntax nutzt, sollte es auf so ziemlich jedem SAP-System lauffähig sein.
Die Unterschiede in Aufbau und Ergebnis zwischen Deinem Testprogramm und dem meinigen sind interessant. Du füllst Deine Hashed-Tabelle, indem Du die Zeilen vorher in eine Standardtabelle einliest und deren Tabellenkörper dann en bloc der Hashed- bzw. Sorted-Tabelle zuweist. Damit kommst Du in der Tat auf Ergebnisse, die zugunsten der Hashtabellen sprechen.
In meinem Testprogramm fülle ich die interne Tabelle zeilenweise, und dabei sieht die Hashtabelle bedeutend schlechter aus, wie Du Dich leicht überzeugen kannst. Ich habe bei Deinem Programm auch mal ausprobiert, was passiert, wenn man den Schlüssel der SORTED TABLE auch UNIQUE definiert (weil es ja bei der Hashed-Tabelle (zwingend) so ist), aber es macht keinen nennenswerten Unterschied.
@Bright4.5: FOR ALL ENTRIES ist ein hervorragender Weg zur Suchzeitoptimierung, weil man damit die Zahl der Tabellenzugriffe minimieren kann. Es setzt allerdings voraus, dass Deine Systemparameter passend zu Deiner Datenbank eingestellt sind. Oracle braucht hier z.B. ganz andere Einstellungen als Sybase. Man sollte die Parameter so setzen, dass ABAP den FOR ALL ENTRIES SQL-seitig in einen IN-Operator übersetzt.
Allerdings halte ich FOR ALL ENTRIES nicht wirklich für eine Alternative zu einem OUTER JOIN. Wenn Du Deine Zusatzfelder im Hauptselect direkt alle lesen kannst, indem Du einfach einen OUTER JOIN dranhängst, dann erscheint mir das auf jeden Fall die optimale Lösung zu sein. FOR ALL ENTRIES ist dann interessant, wenn ein JOIN nicht in Frage kommt, sei es, dass Du das Lesen Deiner Daten sinnvoll modularisieren möchtest, sei es, weil Du nicht über eindeutige Schlüssel liest und unerwünschte Kreuzprodukte vermeiden möchtest. Letzteres wird meist der Hauptgrund sein. Häufig liest man nicht mit vollständigem Tabellenschlüssel, und wenn man dann mal mehrere Ergebnisse bekommt, dann will man im Programm sinnvoll darauf reagieren. Beispiel: Du liest eine Haupttabelle mit, sagen wir, Materialien und aus einer Nebentabelle den Materialtext dazu. Du hast Niederlassungen in verschiedenen Ländern mit verschiedenen Sortimenten mit der Folge, dass nicht jeder Materialtext in jeder Sprache gepflegt ist. In Deinem Anwendungsfall ist Dir das auch egal; Du willst einfach irgendeinen gepflegten Materialtext haben, kannst aber die Sprache beim WHERE nicht angeben, da Du eben nicht genau weißt, welche das sein wird.
Wenn Du jetzt Deine Texttabelle per JOIN (egal ob OUTER oder INNER) an Deinen Haupt-SELECT anflanschst, dann wirst Du bei Materialien, für die mehrere Sprachen gepflegt sind, für jede Sprache eine komplette Ergebniszeile mit allen Materialdaten bekommen, so dass diese Materialien dementsprechend mehrfach in Deiner Ergebnisliste auftauchen. Da halte ich es für besser, erst mal die Ergebnisliste ohne JOIN aufzubauen und dann mit FOR ALL ENTRIES IN zu jedem Material daraus den erstbesten Materialtext dazuzulesen.
Und bei Hashed-Tabellen gibt es keinen SY-TABIX, weil die Zeilen einer Hashed-Tabelle keine Reihenfolge haben. Wenn Du den brauchst, solltest Du immer eine sortierte Tabelle nehmen. Auf Hashed-Tabellen greift man immer über den Schlüssel zu. LOOPs sind zwar auch möglich, aber Du bekommst die Ergebnisse dann in beliebiger (unsortierter) Form. Ein LOOP über eine Hashed-Tabelle macht nur dann Sinn, wenn Du zumindest einen so großen Teilschlüssel angeben kannst, dass Du nur Ergebnisse bekommst, die Du alle haben willst und bei denen die Reihenfolge egal ist.
Genau wie bei relationalen Datenbanken lohnt auch bei Hashed-Tabellen, sich die Theorie davon durchzulesen, bevor man damit arbeitet, da Du andernfalls nicht weißt, was Du tust und damit auch keine nützlichen Ergebnisse damit erzielen wirst.
Zufällig habe ich mein Testprogramm noch gefunden; glücklicherweise habe ich es noch nicht gelöscht. Wie gesagt, ich bin der Meinung, es schon mal gepostet zu haben, aber ich finde den damaligen Thread beim besten Willen nicht wieder.
Wie dem auch sein mag, hier ist es:
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Report ZTEST_TABLE_SEARCH
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZTEST_TABLE_SEARCH.
DATA: T_STANDARD TYPE STANDARD TABLE OF PERSNO WITH HEADER LINE,
T_SORTED TYPE SORTED TABLE OF PERSNO WITH UNIQUE DEFAULT KEY WITH HEADER LINE,
T_HASHED TYPE HASHED TABLE OF PERSNO WITH UNIQUE DEFAULT KEY WITH HEADER LINE,
I TYPE I,
J TYPE I,
RUNTIME TYPE I.
PARAMETERS: ENTRIES TYPE I OBLIGATORY.
*** START-OF-SELECTION ***
START-OF-SELECTION.
* Fill standard table
GET RUN TIME FIELD I.
DO ENTRIES TIMES.
T_STANDARD = SY-INDEX.
INSERT TABLE T_STANDARD.
ENDDO.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Fill Standard table:', RUNTIME.
* Fill sorted table
GET RUN TIME FIELD I.
DO ENTRIES TIMES.
T_SORTED = SY-INDEX.
INSERT TABLE T_SORTED.
ENDDO.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Fill Sorted table:', RUNTIME.
* Fill hashed table
GET RUN TIME FIELD I.
DO ENTRIES TIMES.
T_HASHED = SY-INDEX.
INSERT TABLE T_HASHED.
ENDDO.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Fill Hashed table:', RUNTIME.
* Search standard table
GET RUN TIME FIELD I.
READ TABLE T_STANDARD WITH KEY TABLE_LINE = T_STANDARD.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Search last entry of Standard table:', RUNTIME.
* Search sorted table
GET RUN TIME FIELD I.
READ TABLE T_SORTED WITH KEY TABLE_LINE = T_STANDARD.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Search last entry of Sorted table:', RUNTIME.
* Search hashed table
GET RUN TIME FIELD I.
READ TABLE T_HASHED WITH KEY TABLE_LINE = T_STANDARD.
GET RUN TIME FIELD J.
RUNTIME = J - I.
WRITE: / 'Search last entry of Hashed table:', RUNTIME.
SKIP.
WRITE 'Results are in micro seconds.'.Die Unterschiede in Aufbau und Ergebnis zwischen Deinem Testprogramm und dem meinigen sind interessant. Du füllst Deine Hashed-Tabelle, indem Du die Zeilen vorher in eine Standardtabelle einliest und deren Tabellenkörper dann en bloc der Hashed- bzw. Sorted-Tabelle zuweist. Damit kommst Du in der Tat auf Ergebnisse, die zugunsten der Hashtabellen sprechen.
In meinem Testprogramm fülle ich die interne Tabelle zeilenweise, und dabei sieht die Hashtabelle bedeutend schlechter aus, wie Du Dich leicht überzeugen kannst. Ich habe bei Deinem Programm auch mal ausprobiert, was passiert, wenn man den Schlüssel der SORTED TABLE auch UNIQUE definiert (weil es ja bei der Hashed-Tabelle (zwingend) so ist), aber es macht keinen nennenswerten Unterschied.
@Bright4.5: FOR ALL ENTRIES ist ein hervorragender Weg zur Suchzeitoptimierung, weil man damit die Zahl der Tabellenzugriffe minimieren kann. Es setzt allerdings voraus, dass Deine Systemparameter passend zu Deiner Datenbank eingestellt sind. Oracle braucht hier z.B. ganz andere Einstellungen als Sybase. Man sollte die Parameter so setzen, dass ABAP den FOR ALL ENTRIES SQL-seitig in einen IN-Operator übersetzt.
Allerdings halte ich FOR ALL ENTRIES nicht wirklich für eine Alternative zu einem OUTER JOIN. Wenn Du Deine Zusatzfelder im Hauptselect direkt alle lesen kannst, indem Du einfach einen OUTER JOIN dranhängst, dann erscheint mir das auf jeden Fall die optimale Lösung zu sein. FOR ALL ENTRIES ist dann interessant, wenn ein JOIN nicht in Frage kommt, sei es, dass Du das Lesen Deiner Daten sinnvoll modularisieren möchtest, sei es, weil Du nicht über eindeutige Schlüssel liest und unerwünschte Kreuzprodukte vermeiden möchtest. Letzteres wird meist der Hauptgrund sein. Häufig liest man nicht mit vollständigem Tabellenschlüssel, und wenn man dann mal mehrere Ergebnisse bekommt, dann will man im Programm sinnvoll darauf reagieren. Beispiel: Du liest eine Haupttabelle mit, sagen wir, Materialien und aus einer Nebentabelle den Materialtext dazu. Du hast Niederlassungen in verschiedenen Ländern mit verschiedenen Sortimenten mit der Folge, dass nicht jeder Materialtext in jeder Sprache gepflegt ist. In Deinem Anwendungsfall ist Dir das auch egal; Du willst einfach irgendeinen gepflegten Materialtext haben, kannst aber die Sprache beim WHERE nicht angeben, da Du eben nicht genau weißt, welche das sein wird.
Wenn Du jetzt Deine Texttabelle per JOIN (egal ob OUTER oder INNER) an Deinen Haupt-SELECT anflanschst, dann wirst Du bei Materialien, für die mehrere Sprachen gepflegt sind, für jede Sprache eine komplette Ergebniszeile mit allen Materialdaten bekommen, so dass diese Materialien dementsprechend mehrfach in Deiner Ergebnisliste auftauchen. Da halte ich es für besser, erst mal die Ergebnisliste ohne JOIN aufzubauen und dann mit FOR ALL ENTRIES IN zu jedem Material daraus den erstbesten Materialtext dazuzulesen.
Und bei Hashed-Tabellen gibt es keinen SY-TABIX, weil die Zeilen einer Hashed-Tabelle keine Reihenfolge haben. Wenn Du den brauchst, solltest Du immer eine sortierte Tabelle nehmen. Auf Hashed-Tabellen greift man immer über den Schlüssel zu. LOOPs sind zwar auch möglich, aber Du bekommst die Ergebnisse dann in beliebiger (unsortierter) Form. Ein LOOP über eine Hashed-Tabelle macht nur dann Sinn, wenn Du zumindest einen so großen Teilschlüssel angeben kannst, dass Du nur Ergebnisse bekommst, die Du alle haben willst und bei denen die Reihenfolge egal ist.
Genau wie bei relationalen Datenbanken lohnt auch bei Hashed-Tabellen, sich die Theorie davon durchzulesen, bevor man damit arbeitet, da Du andernfalls nicht weißt, was Du tust und damit auch keine nützlichen Ergebnisse damit erzielen wirst.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
tm987456
Haben über 50 Systeme bei uns. Ich bin meistens auf den alten System unterwegs mit ABAP 7.02.DeathAndPain hat geschrieben:@nickname8: In Deinem Testprogramm schmeißt Du mit Inline-Datendeklarationen um Dich. Und da behauptest Du, auf einem alten Release zu sitzen?
Haben aber auch ein HANA-System zum spielen. Da hab ich es mal kurz umgesetzt, weil ich die INLINE-Deklarationen nutzen konnte. Ist ja nicht wirklich schön strukturiert mein Program...
Danke für das Programm, gucke ich mir an! Sehr nett!
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Du hast nickname8 nicht verstanden. Er wollte von Dir wissen, wozu Du SY-TABIX benötigst. Wenn Du den wirklich brauchst, dann ist das nämlich ein sehr deutlicher Indikator dafür, dass Hashed für Deinen Zweck der falsche Tabellentyp ist.
Vergleichbare Themen
2
Antw.
Antw.
13709
Views
Views
„INTO CORRESPONDING FIELDS OF TABLE“ <--was ist falsch ?
von K0RN » 17.01.2012 16:18 • Verfasst in ABAP® für Anfänger
von K0RN » 17.01.2012 16:18 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
5152
Views
Views
sorted table, hashed table: Übergabe Workarea -> Performa
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
von Jürgen Fischer » 30.01.2006 08:09 • Verfasst in ABAP® Core
5
Antw.
Antw.
9893
Views
Views
1
Antw.
Antw.
2143
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.