ein loop

Re: ein loop

black_adept hat geschrieben:@Dele: Tuning ist immer gut und Kleinvieh macht aus Mist. Und wenn dann ein signifikanter Geschwindkeitszuwachs von 15% wie bei dir erreicht wird ist das nie zu verachten obwohl ich schätze, dass ihr diesen Aufwand nie betrieben hättet, wenn die Transaktion nur 10x am Tag aufgerufen worden wäre.

Aber nichtsdestotrotz möchte ich meine ursprüngliche Frage an adt auch an dich weitergeben. Hast du jemals erlebt, dass das Umstellen von Workarea/Kopfzeile auf Feldsymbol tatsächlich irgend etwas laufzeittechnisch Relevantes gebracht hätte?

Ja, aber das waren meistens Auswertungen mit vielen Daten die in den Speicher geladen werden.
Wobei eine Applikation fällt mir ein, da waren User real betroffen: Übernehmen von Daten aus mehreren Datenquellen in eine bestehende Applikation. Das einzige Selektionskriterium war der Zeitraum. Die Standardapplikation hat hier je nach Datenmenge schon mal gemütliche 50% der Laufzeit "vertrödelt" indem es die Quellstrukturen mittels LOOP AT INTO analysiert hat. Nachdem wir eine eigene Funktion dafür gebaut haben (die zugegebenermaßen nun auch mehr Möglichkeiten bietet) wurde dieser Wert auf 5% maximal(!) gedrückt.

Beim Thema Performance bin ich der gleichen Meinnung wie Dele: Denke global, handle lokal.

Jedes Quentchen an Performanceverlust in einem "kleine" Programm kann bei entsprechend hoher Nutzung zu großen Problemen führen.
Wir haben knapp 5000 concurrent User auf unserem System und die meisten arbeiten über eine Art Portal-Oberfläche die die Arbeitsliste darstellt. Diese selektiert im Standard schon eine rießige Menge an Daten und wir müssen dann darauf aufbauen noch weitere selektieren und verarbeiten. Da machen wir in (leider) unregelmäßigen Abständen Laufzeitanalysen um Flaschenhälse aufzudecken. Meistens kommen da natürlich ungünstige DB-Zugriffe zu Tage, aber hin und wieder taucht da auch ein LOOP AT INTO auf, dem wir dann mit Field-Symbols auf die Sprünge helfen.

Re: ein loop

a-dead-trousers:

Sorry, aber vorallem den letzten Satz kann ich so nicht unkommentiert stehen lassen:
Beim Arbeiten mit Kopfzeilen, werden die Inhalte von der Tabelle in die Kopzeile KOPIERT. Genau gleich wie bei einer WORKAREA (Feldleiste).

Genau auf den Vergleich mit den Workareas habe ich mich auch bezogen, denn die sind ja die propagierte Alternative zu den Kopfzeilen. Man hat die Kopfzeilen ja nicht wegen der Performance deprecated.

Was die Feldsymbole und sonstigen Datenreferenzen angeht, so waren die gerade Thema in einem PN-Austausch zwischen Black Adept und mir. Was ich ihm dazu geschrieben habe, möchte ich auch an dieser Stelle nochmal zum besten geben:

Interne Tabellen über Feldsymbole zu manipulieren ist performant, mir aber dennoch unsymphatisch, weil man dabei sehr leicht aus dem Auge verlieren kann, wann, wo und warum Tabelleninhalte plötzlich mutieren. Im Quellcode ist es ein Segen, wenn man durch die 3000 Zeilen einfach nach dem Namen der internen Tabelle suchen kann und damit alle Stellen ausgeworfen bekommt, an denen damit etwas veranstaltet wird, wobei diejenigen, bei denen der Inhalt verändert wird, durch ein INSERT oder MODIFY explizit gekennzeichnet werden. Das macht das Verständnis und die Analyse insbesondere fremden Codes bedeutend einfacher - und wird von Feldsymbolen wirksam torpediert.

Datenreferenzen sind sowieso der effizienteste Weg sicherzustellen, dass kein anderer Programmierer nachvollziehen kann, was Dein Code da macht.

DELE:

Wir haben vor ein paar Monaten eine Eigenentwicklung getunt. Vorherige durchschnittliche Antwortzeit 510 Millisekunden, was ja eigentlich schon sehr gut ist. Danach 430 Millisekunden. Das hat kein Anwender bemerkt. Aber: die Anwendung hat pro Tag ca.230.000 Dialogschritte.
Ersparnis: ca. 18.400.000 Millisekunden = 18.400 Sekunden = 306 Minuten = 5,11 Stunden

5,11 Stunden klingt viel. Aber 230.000 Dialogschritte... wie viele User müssen das sein, um so viele Dialogschritte am Tag sinnvoll abwickeln zu können? Ich gehe davon aus, dass wir da von einer Organisationsgröße reden, bei der diese 5,11 Stunden absolute Peanuts sind. Sowas muss man immer im Verhältnis sehen. Ich hätte gerne im Monat 10.000 € mehr im Portemonnaie, aber wenn BMW im Monat 10.000 € einsparen würde, dann wäre das nicht mal einen Nebensatz wert.

Haubi:

Naja, die gibt es schon, allerdings sind das dann Programme, bei denen die Tabelle via Feldsymbol geändert wird. Da ist der Vorteil gegenüber einer Feldleiste und MODIFY erheblich.

Auch das halte ich in den allermeisten Fällen für grundfalsch. Dazu müsste nämlich der Anteil des ABAP-Interpreters an der Rechenzeit überhaupt nennenswert sein! Wo kommen denn die Antwortzeiten her, wenn ein Anwender auf "Sichern" klickt (oder sonst einen Schritt macht)? Zum allergrößten Teil von Datenbankanfragen. Heutzutage, da die SAP-Server meist nicht mehr im eigenen Haus stehen, kommen noch Leitungslatenzen als zweiter, durchaus gravierender Faktor hinzu (verschärft von in den Leitungen sitzenden Firmenfirewalls mit ihrer Deep Packet Inspection). Der Anteil des ABAP-Interpreters an der Gesamtantwortzeit ist minimal. Je nach Anwendung wird der irgendwo im einstelligen Prozentbereich liegen. Und wenn man jetzt seine internen Tabellenzugriffe (die ja selbst wiederum nur einen Teil der Interpreter-Rechenzeit ausmachen, sagen wir mal 50%) auf Feldsymbole umstellt, dann hat man von den 5% Interpreterrechenzeit einen Anteil von 2,5% optimiert. Der Optimierungserfolg beträgt, sagen wir, 30%. Also sind diese 2,5% der Gesamtantwortzeit des Systems um 30% besser geworden und machen jetzt nur noch 1,7% der Gesamtantwortzeit des Systems aus.

Damit soll man was bewegen können? Das ist doch ein Witz! Der Preis, den man dafür bezahlt, ist der aus den oben geschilderten Gründen wesentlich schlechter nachvollziehbare Code. Die Rechnung geht nicht auf!

Wenn man ein wirklich lahm laufendes ABAP-Programm hat, bei dem auf das ABAP-Coding tatsächlich wesentliche Teile der Verzögerungen entfallen, dann liegt das in aller Regel an mies programmierten Datenbankanfragen (Index nicht oder schlecht genutzt oder dieselbe Datenbankanfrage 10000x gestellt, anstatt zu puffern) oder opulenter Umgang mit ABAP-Befehlen wie SORT (die sich bei durchdachterer Programmierung immer auf ein performancetechnisch irrelevantes Maß reduzieren lassen sollten). Allenfalls kann man noch was rausholen, indem man interne Tabellen ordentlich sortiert und suchoptimiert darauf zugreift. Habe allerdings noch keinen Berater gesehen, der das macht und ärgere mich fast, dass deren Programme trotzdem so performant zu laufen pflegen, dass keiner was sagt.

Und verglichen mit all diesen Performanceschandtaten soll man was an der Performancefront etwas bewegen können, indem man Feldleisten anstelle von Workareas (egal ob Kopfzeile oder nicht) verwendet? Also mal ernsthaft...

a-dead-trousers:

Die Standardapplikation hat hier je nach Datenmenge schon mal gemütliche 50% der Laufzeit "vertrödelt" indem es die Quellstrukturen mittels LOOP AT INTO analysiert hat. Nachdem wir eine eigene Funktion dafür gebaut haben (die zugegebenermaßen nun auch mehr Möglichkeiten bietet) wurde dieser Wert auf 5% maximal(!) gedrückt.

Aber garantiert nicht dadurch, dass ihr den LOOP AT INTO durch einen LOOP AT ASSIGNING ersetzt habt. Ich behaupte, wenn ihr nur das gemacht hättet, wäre das Ergebnis nicht wahrnehmbar gewesen. Das hättet ihr unter Ulk verbuchen können.

a-dead-trousers:

Beim Thema Performance bin ich der gleichen Meinnung wie Dele: Denke global, handle lokal.

Das Mantra ist richtig, hat aber eine Dimension, die Du anscheinend nicht im Auge hast: Die Wartbarkeit des Codes. Jeder Schritt hin zu einem schlechter nachvollziehbaren Code kostet einen Preis, der nichts mit Performance zu tun hat, gleichwohl jedoch ganz erheblich ist. Für einen Performancegewinn, der so lächerlich ist wie Feldsymbol statt Workarea nebst MODIFY, in Kauf zu nehmen, dass ein anderer Entwickler, der den Code vielleicht mal warten muss, nicht mehr mit wenigen Handgriffen nachvollziehen kann, wo der Inhalt dieser internen Tabelle genutzt wird und wo er insbesondere verändert wird, ist nicht zu rechtfertigen. Ein einziger Bug, der einem durch solch unnötig erhöhte Komplexität reinrutscht, kann ganz locker mehr kosten als alles, was diese Minimalstoptimierung in 20 Jahren an gesparter Arbeitszeit einbringen würde!

Re: ein loop

Richtig. Wer mit "Suchen" die Verwender ermittelt, macht was falsch. Wer einmal gescheit modularisierte Anwendungen zu schätzen gelernt hat, der will so 3000-Zeilen-Monster nicht mehr.


Ralf

Re: ein loop

Ohweh. Ich hatte mich auf ein entspanntes WE gefreut und dann lese ich sowas.

Dass eine Methodendefinition Teil der Klassendefinition ist, ist richtig (im Sinne von "gewollt"). Nur deshalb prüft z. B. die Syntaxprüfung die Typen der Parameter. In Funktionsbaustein-Aufrufen findet diese Prüfung nicht statt, aus genau diesem Grund.

Es steht dir frei, Eclipse oder den Quelltext-Editor mit Splitscreen zu nutzen, um weniger klicken zu müssen. FORMs sind schon deshalb doof, weil man sie nicht von außen ansprechen kann (bzw. soll).

Zum Verständnis bzgl. Debuggen: OO ist eine "Abstraktionsschicht", die Vieles ermöglicht, was ohne sie nicht umsetzbar wäre. Das bedeutet aber auch, dass Menschen, die damit umgehen, ein gewisses Abstraktionsvermögen besitzen und etwas mehr können, als Kommandos hintereinander zu schreiben. Und dass man sich eben mit dieser Abstraktion auch beschäftigt. Man kann eben nicht mehr so einfach drauflos debuggen nach dem Motto "ich sehe ja, was passiert".

Wie Daniel es hier mal schrieb: Ein wichtiger Vorteil von ABAP ist, dass es sich liest wie englische Prosa, so dass es jeder Idiot verstehen kann. Um es nochmal deutlich zu sagen: Die Zeiten sind vorbei!! Das war ein Vorteil für den Kleinkram, den man zu ABAP-Anfangszeiten schrieb. Aber jetzt, wo komplexe Anwendungen in ABAP entstehen (und das ist ja schon eine Weile so), kommt man damit nicht weiter, wenn man das noch wartbar betreiben will.

Ich bin gerade an der Entwicklung einer hoch komplexen Anwendung beteiligt, die intensiv diese Abstraktionsmechanismen nutzt und ich bin dankbar dafür, viele kleine Einheiten zu haben, die in sich selbstständig funktionieren und die miteinander über definierte Schnittstellen kommunizieren.

Ja, die "F5 im Debugger"-Fraktion muss sich weit recken, um das zu verstehen. Aber es lohnt sich - schon deshalb, weil wir extrem viel Coding durch Abstraktion einsparen, weil das vorhandene eben durch diese Abstraktion sehr multifunktionell wird.


Ralf

Re: ein loop

Ihr habt beide recht - er bemängelt ja gerade, dass die Methodenschnittstelle so weit weg von der Implementierung ist. Darum kann man die Signatur in der SE24 ja einblenden.


Ralf

Re: ein loop

Es steht dir frei, Eclipse oder den Quelltext-Editor mit Splitscreen zu nutzen

Das tue ich auch, nachdem mir die SAP mit Release 7.40 meinen geliebten Backend-Editor final abgekniffen hat (ja, ich weiß, aber wenn man die ganzen geisteskranken Hotkeys verinnerlicht hat, kann man damit irrsinnig schnell arbeiten und schlägt locker die Mausmarkier-Frontendfraktion). Da ich mich also ohnehin umgewöhnen musste, habe ich gesagt, ok, dann mache ich gleich den großen Schritt und setze direkt auf den allerneuesten Sch.... Habe es auch nicht bereut. Eclipse ist cool, wenn man sich dran gewöhnt hat.

FORMs sind schon deshalb doof, weil man sie nicht von außen ansprechen kann (bzw. soll).

Und bei privaten Methoden ist das anders? Die wenigsten Unterroutinen in einem strukturiert aufgebauten Programm sollen von außen ansprechbar sein. Soweit dies gewünscht ist, nimmt man bei klassischem Code Funktionsbausteine.

Zum Verständnis bzgl. Debuggen: OO ist eine "Abstraktionsschicht", die Vieles ermöglicht, was ohne sie nicht umsetzbar wäre. Das bedeutet aber auch, dass Menschen, die damit umgehen, ein gewisses Abstraktionsvermögen besitzen und etwas mehr können, als Kommandos hintereinander zu schreiben. Und dass man sich eben mit dieser Abstraktion auch beschäftigt.

Soweit die Theorie. Die funktioniert auch hervorragend, wenn Du das Programm selber geschrieben hast, denn dann kennst Du alle Ideen und Konzepte und kennst genau das Sollverhalten all Deiner Objekte und Methoden.

Aber wie sieht es aus, wenn Du fremden Code warten sollst? Da hast Du dann auch ein Sammelsurium von Klassen, Objekten und Methoden und keinen Schimmer, wozu sie da sind. Und genau hier liegt das Problem: Abstraktion funktioniert nur, solange man sie kennt. Wenn Du nicht weißt, was da abstrahiert wurde, weil die Ideen und Konzepte von jemand anderem sind und dieser jemand wie immer und überall schlecht dokumentiert hat, dann stehste da! Dann hast Du gar keine andere Chance, als mit dem Debugger ranzugehen und zu analysieren, was sein Code da macht, damit Du Dir eine Vorstellung vom Sollverhalten erschließen kannst. Und das ist bei solch Code halt nur sehr schwer möglich.

Wie Du schon sagst, liest sich solch Programm im Prinzip wie Prosa. Die "Befehle", die es nutzt, sind selbstgebaut, denn es handelt sich um Methoden. Und das bedeutet für den Außenstehenden, dass er ein Programm warten soll, bei dem er die Befehle nicht kennt, aus denen es besteht. Also muss er diese einzeln analysieren. Das ist, als ob Du bei einem ABAP-Programm den Kernel disassemblieren oder debuggen müsstest, um Dir die Funktionsweise der ABAP-Befehle zu erschließen.

Besondern schlimm wird es, wenn etwas nicht wie vorgesehen funktioniert. Eine Methode sollte sich von Deinem Verständnis (auch ihrer Benamung) her in gewisser Weise verhalten, aber das tut sie nicht. Dementsprechend läuft auch das ganze Programm nicht wunschgemäß. Irgendwo liegt also ein Bug vor. Jetzt ist die Frage: Sitzt der Bug in der Methode und wäre behoben, wenn sie sich so verhalten würde, wie Du es erwartest, oder ist die Methode in Ordnung und Dein Verständnis ihrer Funktionsweise und Sollverhaltens falsch, und der Bug liegt ganz woanders? Viel Spaß beim Rausfinden!

Ich bin gerade an der Entwicklung einer hoch komplexen Anwendung beteiligt, die intensiv diese Abstraktionsmechanismen nutzt und ich bin dankbar dafür, viele kleine Einheiten zu haben, die in sich selbstständig funktionieren und die miteinander über definierte Schnittstellen kommunizieren.

Dann mach Dir doch mal den Spaß und versetze Dich in die Situation eines externen Beraters (oder Deines Nachfolgers, nachdem Du die Firma verlassen hast). Tausch die Aufgaben mit einem Deiner Kollegen, so dass Du vor den von Dir genannten vielen kleinen Einheiten stehst, freilich seinen und nicht Deinen eigenen, und rausfinden darfst, wofür sie stehen und was ihr genaues bestimmungsgemäßes Sollverhalten ist (erforderlich, um zwischen Bug und Feature unterscheiden zu können und generell zu verstehen, wie das Programm arbeitet). Dabei darfst Du ihn nicht fragen und Dich nicht an etwaiger Papier- oder Dateidoku bedienen, sondern musst am Quellcode bleiben.

Wenn er lehrbuchmäßig gearbeitet hätte, wäre das kein Problem. Da wäre an jeder Klasse eine Klassendokumentation, an jeder Methode eine Methodendokumentation, sie alle würden die entsprechenden abstrakten Gedanken und Konzepte beschreiben, und man könnte Sollverhalten und Verwendungsweise dieser Elemente einfach nachlesen und sich zurechtfinden. SAP bietet ja üppig Ablagemöglichkeiten für derartige Texte.

Aber ohne zu wissen, welchen Kollegen Du Dir für dieses Experiment aussuchst, behaupte ich: Da ist wenig bis gar nix. Wenn Du Glück hast, stehen mal drei Zeilen Text in einer Klassendoku, aber spätestens auf Methodenebene ist keinerlei Online-Doku mehr vorhanden. Das ist ja sogar beim Original-SAP-Quellcode nicht anders. Und genau das ist die Stelle, an der Du Dir die Karten legst und an der die Abstraktion vom Segen zum Fluch wird.

Innerhalb eines Beratungshauses hat man in der Regel noch eine gewisse Doku, in Dateien und teils auch auf Papier. Da gibt es einen Projekt-Blueprint, gerne mit dreistelliger Seitenzahl, und da mag es auch Word-Dokumente für die einzelnen Teilmodule des Konzeptes geben, in denen die Klassen genannt sind und deren Funktionsweise geschildert wird. So geht z.B. auch die SAP vor; das ist der Grund, weshalb die ihren eigenen Code noch warten können. Aber sobald ein Außenstehender da was tun soll, ist er ganz bitterlich aufgeschmissen. Und das ist die große Kehrseite der Objektorientierung.

Im übrigen ist es durchaus nicht so, dass alle Programmieraufgaben heute Großprojekte sind, die ohne entsprechende Abstraktion nicht zu handhaben sind. Im Gegenteil behaupte ich, der Beratungsalltag besteht aus vergleichsweise kleinen Projekten. Da braucht man hier mal einen Report, dort mal einen User Exit, um das Systemverhalten nach Kundenwunsch anzupassen. Und in dem Bereich kommt man prozedural bedeutend schneller zum Ziel, und zwar unter Erzeugung eines Codes, der mitnichten schlechter zu warten ist als OO, ganz im Gegenteil!

Für richtige Mammut-Großprojekte mag OO durchaus richtig sein, kombiniert mit einer disziplinierten, ausführlichen Dokumentation (die - zusätzlich zur üblichen Dateidoku - online direkt an den jeweiligen OO-Objekten erfolgen sollte, außer ich verfolge die Strategie, den Kunden durch Vorenthalten brauchbarer Onlinedoku an mein Beratungshaus zu binden, weil niemand sonst das warten kann). Aber für die meisten Entwickler sind solche Großprojekte nicht der Alltag.

Re: ein loop

Natürlich hängt die Qualität einer Entwicklung auch an ihrer Dokumentation. Darum ist - eben aufgrund der höheren Abtraktionsebene - die Doku auch besonders wichtig und sollte nicht einfach weggelassen werden. Sie ist Bestandteil des Codings und ich würde keinen Berater wegschicken, ohne dass er sein Coding gescheit dokumentiert hat.

In der Praxis läuft es aber in aller Regel anders.

Der Vorteil dabei ist: Es fordert zum Dokumentieren auf, man darf den Ruf halt nicht überhören.

Gut dokumentieren war schon zu allen Zeiten ratsam und angesagt. Die Tatsache, dass man bei herkömmlichem Code ohne Doku noch eine Chance hat und bei OO nicht, soll jetzt ein Vorteil von OO sein?!? Das finde ich doch eine sehr verquere Logik.

Leider, und das finde ich ganz, ganz übel und wurde von mir mit Horst Keller diskutiert, fehlt in Eclipse eine übersetzbare, versionierte Dokumentationsmöglichkeit am Objekt wie die SE80 sie bietet.

Die kommt ja vielleicht noch. Der Self-Updater von Eclipse findet ja alle paar Tage was Neues. Wobei kürzlich (im Rahmen einer neuen Version) allerdings nicht etwas Neues gekommen, sondern etwas verschwunden ist. In der Vergangenheit konnte ich über das Menü Navigate -> Open Others direkt in die Pflege der Texte zum Programm abspringen. Dieser Menüpunkt ist jetzt in Oxygen nicht mehr da. Weiß Du zufällig, wo er geblieben ist?

Ich habe übrigens schon viele Fremdanwendungen gewartet, und das ist bei den 3.000-Zeilen-Monstern, in denen ein "X" vom Himmel fällt und was tut, auch nicht einfacher.

Da sind wir deutlich unterschiedlicher Meinung.