gelöst Performance Field-Symbols bei nur lesender Verwendung


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

gelöst Performance Field-Symbols bei nur lesender Verwendung

Beitragvon KleinerEisbaer » 04.02.2019, 13:15

Hallo Miteinander,

haben Field-Symbols auch Performancevorteile, wenn keine Änderung einer internen Tabelle erfolgt, sondern lediglich in einem LOOP oder nach einem READ TABLE ein lesender Zugriff stattfindet?

Sind diese Anweisungen also stets performanter …
Code: Alles auswählen
LOOP AT it_itab ASSIGNING <fs_struc>.

ENDLOOP.

READ TABLE it_itab ASSIGNING <fs_struc>
WITH KEY matnr = lv_field.
 

… als diese:
Code: Alles auswählen
LOOP AT it_itab INTO ls_struc.

ENDLOOP.

READ TABLE it_itab INTO ls_struc
WITH KEY matnr = lv_field.
 

Danke für Euer Feedback!
KleinerEisbaer
Specialist
 
Beiträge: 121
Registriert: 24.08.2007, 10:25
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon DeathAndPain » 04.02.2019, 14:19

Ja, da keine Daten von einem Feld in ein anderes bewegt werden müssen, sondern nur ein Zeiger bereitgestellt wird.

Aber anstatt hier solche Fragen zu stellen, solltest Du die Laufzeit einfach selber messen, z.B. mit dem Befehl GET RUN TIME FIELD... Dann haste die Erkenntnisse aus erster Hand.

Möglicherweise sind solche Erkenntnisse auch präziser als die Antworten, die Du hier bekommen wirst. Ich musste beispielsweise feststellen, dass SORTED TABLEs effizienter sind als HASHED TABLES, wenn die ganze Tabelle nur aus Schlüsselfeldern besteht. Sobald die Tabelle auch (mindestens) ein Nichtschlüsselfeld enthält, ist es andersrum. Das sind Sachen, die kaum einer aus dem Kopf wissen und Dir sagen wird. Rasch selber messen ist aber kein Problem, wenn man ABAP kann.

Für diese Nachricht hat DeathAndPain einen Dank bekommen :
KleinerEisbaer
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon black_adept » 04.02.2019, 15:16

Ich weiß nicht ab welchem Release SAP es macht - aber für dein "LOOP ... INTO " gibt SAP auf einem recht neuen System in der erweiterten Syntaxprüfung den Hinweis:
Here, LOOP AT ... ASSIGNING is very likely to be faster than LOOP AT ... INTO LS_STRUC.
Deactivatable using pragma ##INTO_OK. Message Code UNR 0261
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
KleinerEisbaer
black_adept
Top Expert
 
Beiträge: 3184
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 553 mal
Ich bin: Freiberufler/in

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon DeathAndPain » 04.02.2019, 15:44

Die erweiterte Programmprüfung (bzw. der Code Inspector; ich verwechsele die beiden immer) sind sowieso sehr nützliche Tools, die man über das fertige Programm mal rüberrattern lassen sollte. Viele Meldungen sind zwar unwichtig, aber allein schon die ganzen Felder, die man definiert, am Ende aber gar nicht verwendet hat und die man daher aus dem Code streichen kann, wodurch dieser kürzer und übersichtlicher wird, sind es schon wert. Und wer jetzt sagt, dass ihm das kaum passiert mit solchen Feldern - ja, davon bin ich auch immer überzeugt, und wenn die Prüfung dann rübergelaufen ist, dann mache ich große Augen...
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon black_adept » 04.02.2019, 16:11

DeathAndPain hat geschrieben: aber allein schon die ganzen Felder, die man definiert, am Ende aber gar nicht verwendet hat und die man daher aus dem Code streichen kann, wodurch dieser kürzer und übersichtlicher wird, sind es schon wert. Und wer jetzt sagt, dass ihm das kaum passiert mit solchen Feldern - ja, davon bin ich auch immer überzeugt, und wenn die Prüfung dann rübergelaufen ist, dann mache ich große Augen...
Für diesen ganz speziellen Fall kann ich eigentlich nur Eclipse empfehlen - irgendwo da gibt's einen Menüpunkt "unbenötigte Variablen entfernen"
DeathAndPain hat geschrieben:Die erweiterte Programmprüfung (bzw. der Code Inspector; ich verwechsele die beiden immer) sind sowieso sehr nützliche Tools, die man über das fertige Programm mal rüberrattern lassen sollte. Viele Meldungen sind zwar unwichtig,...
Und SAP erweitert die Prüfungen von Zeit zu Zeit, und es ist fast immer möglich das Coding (evtl. mit den angebotenen Pragmas ) auf 0 Fehler in der SLIN zu bringen. Selbst wenn man einige Prüfungen für unwichtig hält - manchmal sind es ganz kuriose Meldungen, wo man sich fragt:"Höh???"
Und wenn man dann die Erklärung von SAP liest überlegt man sich evtl. den eigenen Programmierstil ein wenig zu überarbeiten.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3184
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 553 mal
Ich bin: Freiberufler/in

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon DeathAndPain » 04.02.2019, 16:34

Für diesen ganz speziellen Fall kann ich eigentlich nur Eclipse empfehlen - irgendwo da gibt's einen Menüpunkt "unbenötigte Variablen entfernen"

Du hast recht, der Punkt ist da, aber da hätte ich Hemmungen, den einzusetzen, weil er kommentarlos durchrattert und man hinterher nicht weiß, was er gemacht hat. Und es gibt ja nun mal auch indirekte Verwendungen von Variablen. Da kann man sich ganz schnell automatisiert das Programm zerschießen lassen. Im allgemeinen wird man zwar wissen, ob man indirekte Aufrufe drin hat, aber da vergisst man leicht mal irgendwas und hat dann nachher die seltsamsten Programmeffekte. Da ist mir eine Programmprüfung, die mir die Stellen zeigt und mich bewusst entscheiden lässt, was davon weg kann, bedeutend lieber. Das Programm zu schreiben hat 5 Stunden gekostet. Die 5 Minuten, die unbenutzten Felder durchzusehen, habe ich dann auch noch.

Und SAP erweitert die Prüfungen von Zeit zu Zeit, und es ist fast immer möglich das Coding (evtl. mit den angebotenen Pragmas ) auf 0 Fehler in der SLIN zu bringen.

Wenn das möglich wäre, würde ich es anstreben, aber leider gibt es viele Meldungen, die "durch ein Pragma nicht ausblendbar" sind, weil die SAP oberlehrerhaft entschieden hat, dass dem Anwender nicht die Möglichkeit gegeben werden darf, sich davon nicht nerven zu lassen. Und wenn ich eh nicht auf Null kommen kann, dann fange ich gar nicht erst mit den Pragmas an, sondern prüfe halt einmal das fertig entwickelte Programm und schaue durch, welche Meldungen Quatsch sind und welche nicht. Besonders nervig ist das deswegen, weil Eclipse diese Warnungen auch immer ungefragt hochpoppen lässt und man das nicht verhindern kann (wohingegen Eclipse ausblendbare Warnungen von sich aus erst mal nicht bringt, auch wenn man sie nicht ausgeblendet hat).

Erschwerend kommen Bugs hinzu. Ich kann mich erinnern, dass der Befehl CALL FUNCTION die Parameter in genau dem Datentyp haben wollte, der im Baustein definiert ist. Hat man aus diesem Grund beim CALL FUNCTION den Parameter aber mit CONV( ) wandeln lassen, dann kam eine Programmprüfmeldung, dass man eine unnötige Wandlung drin hätte. Mittlerweile akzeptiert der CALL FUNCTION aber offenbar andere Datentypen und wandelt sie implizit (vorausgesetzt, dass das möglich ist).

Genauso war es anfangs (nach Einführung von 7.40) nicht möglich, per APPEND VALUE #( ... ) eine Zeile an eine Tabelle anzufügen. Man musste statt des # den genauen Zeilentyp der Tabelle angeben. Nur durch Zufall ist mir irgendwann aufgefallen, dass es inzwischen geht.

Selbst wenn man einige Prüfungen für unwichtig hält - manchmal sind es ganz kuriose Meldungen, wo man sich fragt:"Höh???"
Und wenn man dann die Erklärung von SAP liest überlegt man sich evtl. den eigenen Programmierstil ein wenig zu überarbeiten.

Grundsätzlich gebe ich Dir da recht. Interessant sind die Meldungen allemal. Aber viele haben auch einen hohen Nerv-Faktor - etwa wenn er bei jedem einzelnen SELECT SINGLE anmeckert, dass Du schon wieder nicht den vollständigen Primärschlüssel angegeben hast (obwohl Du genau weißt, dass Du a) nur eine Zeile bekommen kannst oder b) Dir eine der möglichen Zeilen langt, egal welche Du kriegst). Das kommt bei mir eigentlich auch nicht vor, dass ich unbewusst "vergesse", ein bedeutsames Feld des Primärschlüssels mitzuprüfen. Von daher hat diese Meldung nie eine Bedeutung für mich.
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Performance Field-Symbols bei nur lesender Verwendung

Beitragvon black_adept » 04.02.2019, 19:46

DeathAndPain hat geschrieben:
Und SAP erweitert die Prüfungen von Zeit zu Zeit, und es ist fast immer möglich das Coding (evtl. mit den angebotenen Pragmas ) auf 0 Fehler in der SLIN zu bringen.

Wenn das möglich wäre, würde ich es anstreben, aber leider gibt es viele Meldungen, die "durch ein Pragma nicht ausblendbar" sind, weil die SAP oberlehrerhaft entschieden hat, dass dem Anwender nicht die Möglichkeit gegeben werden darf, sich davon nicht nerven zu lassen.
Was fällt dir denn aktuell ein, was nicht in der SLIN auspragmatisierbar wäre und was du auch bewusst nicht ändern willst? Zwei bis drei hinreichend unterschiedliche Beispiel hätte ich gern mal.
DeathAndPain hat geschrieben:[...] Aber viele haben auch einen hohen Nerv-Faktor - etwa wenn er bei jedem einzelnen SELECT SINGLE anmeckert, dass Du schon wieder nicht den vollständigen Primärschlüssel angegeben hast (obwohl Du genau weißt, dass Du a) nur eine Zeile bekommen kannst oder b) Dir eine der möglichen Zeilen langt, egal welche Du kriegst). Das kommt bei mir eigentlich auch nicht vor, dass ich unbewusst "vergesse", ein bedeutsames Feld des Primärschlüssels mitzuprüfen. Von daher hat diese Meldung nie eine Bedeutung für mich.
Du schreibst, dass du die Zeit hast 5 Minuten für das Ausdünnen von nicht mehr verwendeten Variablen aufzubringen - mit dem selben Argument könntest du auch das zugehörige Pragma bei denjenigen Select-Singles reinwerfen, wo du es für nötig hältst. Und das "0-Fehler-Prinzip" sorgt halt auch dafür, dass nicht nur DU weißt, dass dort ein Partialschlüssel ausreichend ist, sondern falls das mal von jemand anderem gewartet/debuggt werden muss und er ein Pragma sieht kann er das als mögliche Fehlerquelle schon mal in der Prioritätsliste nach unten schieben.
Und jetzt winke ich auch noch mal mit der Horst-Keller-Keule und weise darauf hin, dass in dem Fall wo dir die zurückgegebene Zeile egal ist, von SAP empfohlen wird ein "SELECT UP TO 1 ROWS" zu machen was dann auch zur Folge hat, dass die Fehlermeldung nicht mehr auftaucht.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3184
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 553 mal
Ich bin: Freiberufler/in


Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Adobe Forms - Download - Keine Seiten
vor 11 Stunden von shimsham 2 Antw.
UTF-8 mit Funktionsbaustein
vor 13 Stunden von a-dead-trousers 4 Antw.
gelöst Fehler SAVE NOT ALLOWED bei F4IF_START_VALUE_REQUEST
vor 10 Stunden von AdrianSchm 1 Antw.
SAP Logon bei Aufruf WebGUI
Gestern von msfox 0 Antw.
Formatierung Textdatei aus Query und ABAP
vor 13 Stunden von wreichelt 5 Antw.

  Ähnliche Beiträge beta
field symbols
20.10.2006, 16:01 von zzcpak 7 Antw.
FIELD-SYMBOLS
18.08.2008, 10:29 von GastX 10 Antw.
Field-Symbols
23.08.2012, 16:05 von ralf.wenzel 13 Antw.
Field Symbols
15.07.2014, 12:57 von a-dead-trousers 13 Antw.
field-symbols definierung
13.07.2005, 12:40 von babap 7 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]

cron