Gehaltsvorstellungen SAP ABAP-Entwickler

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

DeathAndPain hat geschrieben:hundsmiserable Performance von OO

boaey, geht das schon wieder los?

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Das kann gut sein. Nur machst Du den Fehler, das Modul, das ihr baut, als Maßstab für die gesame Entwicklergemeinde zu betrachten. Es gibt Ecken, in denen ist Performance relevant und andere, da ist sie es nicht. Da muss man immer auf den Kontext achten.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Kommt drauf an, wo und wie. Meine Lieblingsschätzchen sind zwei Programme, die aus ganz vielen Tabellen Werte zusammensuchen und eine Ergebnisliste daraus bauen. Dabei ist all diesen Quelltabellen gemein, dass sie periodenbasiert sind, soll heißen, dass sie Spalten BEGDA und ENDDA haben. Für jeden Mitarbeiter kann sich jederzeit in einer dieser Tabellen ein Wert ändern. Dann muss eine neue Tabellenzeile erzeugt werden, bei der alle anderen Werte gleich bleiben, aber der eine Wert sich halt ändert (mit BEGDA und ENDDA dieser Tabellenzeile entsprechend gesetzt). Da habe ich endlos viele und zudem geschachtelte Iterationen; da ist ABAP-Performance richtig bedeutsam (da ich die Datenbanktabellenzugriffe einmal zu Programmbeginn per SELECT FOR ALL ENTRIES IN puffere, was die Datenbankzugriffszeit auf einen winzigen Bruchteil reduziert). Wenn ich da OO einsetzen würde, dann würde die Laufzeit drastisch ansteigen. Das fängt schon bei so simplen Sachen an wie Tabellenzugriff mit 7.40-Syntax nebst CATCH CX_SY_ITAB_LINE_NOT_FOUND. Wie ich an anderer Stelle gemessen und hier berichtet habe, steigt damit im Falle des Nichtvorhandenseins der Zeile die Laufzeit des Tabellenlesezugriffs auf das Siebenfache.

Aber klar, wenn Du nur einfache Zugriffe außerhalb von Iterationen hast, dann kannst Du Dir auch luxuriöse Performance Hogs wie in Klassen gekapselte Funktionsbausteine und Getter/Setter-Methoden für jedes Attribut leisten, ohne dass der Anwender etwas davon merkt.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Ich habe das nur am Rande erwähnt, um dem naheliegenden Argument vorzubeugen, dass die Datenbankzugriffe in aller Regel den erdrückenden Löwenanteil der Programmlaufzeit auszumachen pflegen, so dass die ABAP Performance kaum interessiere. Deshalb habe ich es auch in Klammern gesetzt, die Du aber nicht mitzitiert hast (und das bedeutet sofort: falsch zitiert!)

Wenn Dir das klar ist, kannst Du Dir die Klammer samt Inhalt in meinem Text gerne wegdenken.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

DeathAndPain hat geschrieben:Ich habe das nur am Rande erwähnt, um

gegen OO zu stänkern mit einem Thema, das mit OO nichts zu tun hat.


Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

DeathAndPain hat geschrieben:Da hast Du vollkommen recht, und das wollte ich auch nicht behaupten. Ich wollte nur darauf hinweisen, dass bei der kleinsten Verwendung von OO-Elementen, wie eine solche Ausnahmeklasse sie darstellt, sofort die ABAP-Performance eklatant einknickt.

Das ist so nicht richtig, wenn man die Funktionalität dagegen hält. Immerhin halten Kaskaden von Ausnahmeklassen ganze Protokolle im Speicher, die man zum Beispiel ins Application Log schreiben kann. Das kannst du auch prozedural nicht nennenswert schneller machen. Du fragst den sy-subrc ab und sagst, das gehe schneller. Klar geht das schneller, aber das musst du ja irgendwie gescheit verarbeiten. Und diese Verarbeitung ist, bei entsprechender Komplexität, ein Performancefresser (ich nehme mal das provokante Wort, weil SO schlimm kann das nicht sein, sonst hätten wir das im Projekt gemerkt).

DeathAndPain hat geschrieben:Funktionsgruppen haben ja so große Ähnlichkeiten mit Klassen

Nein. Außer, dass beide aus ABAP-Coding bestehen, gibt es praktisch keine Parallelen. Ich kann (ohne Dirty Assign) nicht von außen auf Attribute einer Funktionsgruppe zugreifen (streng genommen HAT eine Funktionsgruppe keine Attribute, sondern Variablen, weil sie keinen Zustand hat). Ich kann auch keine Hilfs-Funktionsbausteine als geschützt deklarieren, damit sie nicht von außen im Zugriff sind. Dieses Problem habe ich gerade bei einem RFC-Funktionsbaustein, der eigentlich von anderen nicht aufgerufen werden darf. Es gibt auch keine Vererbung, ich kann nicht mehrere Funktionsgruppen-Instanzen im Speicher halten. Sprich: Ich muss dem Funktionsbaustein zum Verbuchen einer Blutspende stets alle Daten mitgeben, weil es eben nur eine Instanz gibt (darum hat eine Funktionsgruppe auch keinen Zustand, weil es eh nur eine Instanz gibt). Das Interface einer Funktionsgruppe besteht aus den Funktionsbausteinschnittstellen. Ich kann also nicht eine Teilfunktionalität an eine (wie auch immer realisierte) Prozedur übergeben. Genau genommen: Ich kann eine Funktionsgruppe oder einen Funktionsbaustein überhaupt nicht an eine Prozedur übergeben.

Und bis zu diesem Punkt habe ich noch nichtmal darüber NACHGEDACHT, welche Unterschiede mir noch so einfallen....

Ein Flugzeug hat Reifen, ein Fahrrad auch. Trotzdem muss man schon ziemlich schräg denken, das Fahrrad als Vorläufer des Flugzeuges zu betrachten. Nicht alles, was hinkt, ist ein Vergleich.


Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Ralf hat geschrieben:Das ist so nicht richtig, wenn man die Funktionalität dagegen hält.

Du beharrst darauf, nicht beim Thema zu bleiben. Dass OO viele Funktionalitäten bietet, die ohne nicht (bzw. nur auf Umwegen) erreichbar sind, ist unbestritten, hat aber mit der Performance nichts zu tun. Und wenn ich Daten für eine komplizierte Liste bereitstellen muss, bei der ich aus vielen Tabellen mit vielen Iterationen die Ergebniszeilen zusammenbasteln muss, dann nützen mir Kaskaden von Logs nichts, aus denen ich ersehen kann, an welcher Stelle mein Programm wegen Timeouts abgebrochen hat. Dann brauche ich einfach effizienten Code ohne Ballast.

An anderen Stellen ist die Performance praktisch gegenstandslos und Deine Funktionalitäten dafür wichtiger. Bei Deinem Blutspendeprojekt scheint das so zu sein. Das muss man fallweise entscheiden.

Ralf hat geschrieben:Nein. Außer, dass beide aus ABAP-Coding bestehen, gibt es praktisch keine Parallelen.

Da bin ich anderer Meinung. Natürlich sind Klassen viel neuer und damit ausgefeilter und umfassender. Man kann Funktionsgruppen als Vorläufer der Klassen bezeichnen. Aber wie Klassen enthalten Funktionsgruppen eine Ansammlung aufrufbarer Unterroutinen mit definierter Parameterschnittstelle, wie bei Klassen kann ich in Funktionsgruppen Werte verstecken, die Zustände definieren und von außen (legal) nicht zugreifbar sind, wie bei Klassen kann ich Ausnahmen zurückliefern (auch wenn man bei Klassen mehr damit anstellen kann). Klassen haben diverse Vorteile, weil bei ihnen das Konzept eben erheblich weiterentwickelt ist. Dafür haben Funktionsbausteine allerdings einen Vorteil, den ich persönlich als sehr gravierend wahrnehme: Sie bieten hervorragende Unterstützung von Online-Dokumentation bis hinunter zur plakativ angeboteten Detaildoku jedes einzelnen Parameters und jeder einzelnen Ausnahme an, während die Online-Dokumöglichkeiten von Methoden versteckt über das Menü, wo eh nie jemand reinschaut, nur als stiefmütterlich bezeichnet werden können.

ewx hat geschrieben:Aber die Aussage, "dass bei der kleinsten Verwendung von OO-Elementen [...] sofort die ABAP-Performance eklatant einknickt." ist definitiv falsch.

Jein. Ich halte das für eine Blickwinkelfrage. Der einzelne Befehl wird mit OO erheblich langsamer. Im Kontext betrachtet hat man aber in einem Benutzerdialog vielleicht eine Laufzeit von 200 ms, bis das nächste Fenster auf dem Schirm steht. Selbst wenn sich diese auf 400 ms verdoppeln würde, würde der Anwender es kaum wahrnehmen, so dass man nicht von einem unperformant laufenden Programm reden könnte. Diesen oder vergleichbare Fälle hat man oft in der Praxis, so dass die besseren Abstraktionsmöglichkeiten von OO durchaus ausschlaggebende Vorteile bieten können. Allerdings nach meiner Überzeugung eben nur bei hochkomplexen Großprojekten wie Ralfs Blutspendedienst, deren Komplexität mit konventionellen Programmiermethoden nicht beherrschbar ist, so dass man in den sauren Apfel beißen und zu OO-Code greifen muss, den später kein Projektfremder mehr versteht, wenn er nicht vorher seitenweise die Dokus der ganzen Objekte liest und versteht. Dazu müssen diese Dokus freilich existieren und detailliert und verständlich geschrieben sein. Gerade Letzteres ist ein bedeutsamer Engpass, denn die meisten Menschen (und ich rede noch nicht mal von Ausländern) sind gar nicht fähig, detaillierte Zusammenhänge strukturiert und nachvollziehbar in Worte zu kleiden. Und nun lass noch Englisch als Projektsprache gefordert sein... Es ist einfach ein nicht zu unterschätzender Vorteil, wenn man noch eine Chance hat, sich aus dem Programmcode selbst dessen Funktionsweise zu erarbeiten. Auch dann, wenn noch der eine oder andere Bug vorhanden ist (was bei Klassen auch bitter ist, denn wenn ich versuche, eine Klasse zu verstehen und diese sich dann nicht sollgemäß verhält, dann lege ich mir die Karten angesichts der Frage, ob das ein Bug ist oder ich nur noch nicht richtig verstanden habe, wie die Klasse funktioniert).

Wenn ich in meinem Programm mit seinem vielen Iterationen über die internen Tabellen mit den Teilwerten jetzt aber anfangen würde, aus den internen Tabellen Containerobjekte zu machen und - überspitzt formuliert - jeden READ TABLE durch den Aufruf einer GETter-Methode zu ersetzen, die sich dann über diverse Dereferenzierungen den Wert besorgt, dann habe ich keine Zweifel, dass das absolut verheerend für die Programmlaufzeit wäre.

ewx hat geschrieben:Beim Aufruf eines Funktionsbausteins wird übrigens die gesamte Funktionsgruppe in den Speicher geladen, beim Aufruf einer Methode nur der Sourcecode dieser Methode...

Du meinst, die zugehörige Klasse mit ihren Attributen usw. wird nicht in den Speicher geladen? Ist das Dein Ernst?!? Eine Klasse ist ein Rahmenprogramm. Ohne dieses sind die zugehörigen Methoden doch gar nicht funktionsfähig!

Möglicherweise wird bei Klassen der Quelltext anderer Methoden nicht in den Hauptspeicher geladen, wenn eine Methode aufgerufen wird. Da stecke ich nicht tief genug im Kernel drin, um das beurteilen zu können. Aber der Speicherbedarf von Quelltexten ist heutzutage ja ein Lacher. Selbst wenn der Quelltext als unkomprimiertes ASCII geladen werden würde, reden wir bei 1000 Zeilen Code nur von ein paar kb. Tatsächlich hoffe ich, dass der ABAP-Compiler zumindest das kann, was schon der BASIC-Interpreter des C64 konnte, nämlich aus Schlüsselwörtern (Befehlen) Tokens zu machen, die im Hauptspeicher dann nur noch ein Byte belegen.

ewx hat geschrieben:Pack doch mal eine oder zwei zentrale Funktionen deines Lieblingsprogramm mit einem Demodatenbestand von x Datensätzen auf github und wir schauen mal, ob es überhaupt relevant ist, mit welcher Methodik es programmiert wird und was sich für Vorteile ergeben, wenn man es evtl. doch objektorientiert aufbaut...

Ich kann nicht einfach Firmencode ins Internet hochladen. Zumal sich einzelne Funktionen nicht wirklich isoliert betrachten lassen, sondern sich das über die Iterationen verzahnt. Im Prinzip habe ich eine Tabelle von Mitarbeitern (da könnteste im MM aber genauso gut Materialien nehmen). Zu diesen lese ich jetzt innerhalb eines Zeitraums einen Wert, sagen wir, die Mitarbeitergruppe. Immer, wenn sie sich ändert, erzeuge ich eine neue Zeile. Ändert sich für Mitarbeiter X im Zeitintervall also zweimal die Mitarbeitergruppe, dann hat er in der Ergebnistabelle hinterher drei Zeilen.

Jetzt nehme ich diese Ergebnistabelle und lese das nächste Attribut, sagen wir, den Mitarbeiterkreis. Für jede einzelne Zeile der Ergebnistabelle, also nicht nur für jeden Mitarbeiter, sondern auch für jeden einzelnen bereits in der Tabelle bestehenden Teilzeitraum muss ich jetzt nicht nur den Mitarbeiterkreis lesen, sondern schauen, ob dieser sich möglicherweise innerhalb dieses Teilzeitraums ändert, womöglich sogar mehrfach ändert. Dann muss ich diese Tabellenzeile in entsprechend viele Unterzeilen aufteilen, die alle dieselbe Mitarbeitergruppe haben, aber unterschiedliche Mitarbeiterkreise.

Dann mache ich dasselbe mit dem nächsten Attribut. Dann wieder mit dem nächsten. Usw. Das eine der beiden Programme hat 92 Attribute, die auf diese Weise gelesen werden! Und nicht alle davon stehen im Klartext in der Datenbank, sondern müssen z.T. selber erst ermittelt werden. Wenn ich beispielsweise den Vorgesetzten des Mitarbeiters ermitteln möchte, dann muss ich dafür die (zuvor ermittelte) Planstelle des Mitarbeiters nehmen, deren Organisationseinheit ermitteln, schauen, ob diese eine Führungsplanstelle hat, hat sie nicht, also die übergeordnete Orgeinheit ermitteln, schauen, ob die eine Führungsplanstelle hat, hat sie, dann den Inhaber dieser Führungsplanstelle ermitteln, schauen, ob der überhaupt aktiv ist (er könnte z.B. auch in Sabbatical oder in Elternzeit sein, was dann bedeuten würde, dass ich entweder einen anderen Planstelleninhaber finden oder doch wieder eine Orgeinheit nach oben gehen muss), und dann erst habe ich die Personalnummer des Vorgesetzten.

Nun kann es natürlich auch passieren, dass sich innerhalb des Zeitraums der Inhaber der Führungsplanstelle ändert, was dann bedeutet, dass der Vorgesetzte sich ändert und ich damit wieder in zwei Tabellenzeilen aufteilen muss.

Von daher sind Werkzeuge zur Abstraktion hier eigentlich interessant. Aber wenn ich da mit Objekten und Methoden jongliere, dann geht mir die Performance dermaßen in die Knie, dass das Ganze nicht zu gebrauchen ist.