Performance Field-Symbols bei nur lesender Verwendung

Re: Performance Field-Symbols bei nur lesender Verwendung

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.

Re: Performance Field-Symbols bei nur lesender Verwendung

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...

Re: Performance Field-Symbols bei nur lesender Verwendung

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.