View Full Version : Litreatur iseries --> z. B. Performance
peterspeer
20-06-12, 15:03
Hallo Zusammen,
kann mir jemand Literatur empfehlen, die einen groben Überblick über Entwicklungsaspekte auf aktuellem Stand der iseries (V6 oder neuer) beinhaltet.
Z. B. habe ich früher mal gelernt, dass RPG-Programme, die mit der Option *Debug=YES compiliert wurden schlechtere Performance hatten.
Oder das man ein Programm dahingehend beschleunigen konnte, indem die *INZSR ans Ende des Programmcodes kommt, da diese immer sofort eingelesen wird- und somit das Programm ganz im Speicher ist.
Das sind aber alles Weisheiten, die 10 Jahre und älter sind - ist dem heute noch so?
Und stimmt es heute noch, dass man interne Datenstrukturen möglichst kein halten soll, da die sonst zu viel Spieicher/Performance benötigen - habe gehört, dem wäre heute nicht mehr so, man kann also ruhig mal 100 oder 200 Stellen frei lassen, um für eine neue Variable die Datenstruktur nicht immer anpassen zu müssen und somit nicht immer alle Programm neu compilieren zu müssen....
Solche Dinge würde ich gerne mal irgendwo nachlesen können.
Hier hat mich aber "Onkel Google" vollkommen alleine gelassen.
Wenn jemand hier einen guten Hinweis hat wäre ich sehr dankbar.
Gruß
Peter Speer
Ich weiß ja nicht wo deine Aussagen überhaupt herkommen, aber ich denke dass dies noch zu Diskettenzeiten galt, als Programme seitenweise nachgeladen wurden und der Speicher knapp war und das Ganze noch vor der AS/400, also z.B. /36.
Mit Einführung der Festplatte und der AS/400 erübrigen sich solche Gedankenspiele wohl eher bzw. sind eher sinnlos und ich glaube auch nicht, dass es dazu noch Dokumentation gibt.
Zum Thema Performance gibt's sicherlich etwas über die Performance-Tools, was die so machen und optimieren können.
Zusätzlich dann noch im Bereich SQL (VisualExplain, Indizes, ...) wie man so eine Anwendung optimieren kann.
Bei der klassischen Programmierung mit F-Bestimmungen lebt man eher aus Erfahrung als dass es da Dokumentation gibt, wie man performante Programme schreibt.
Was den Programmspeicher angeht, so kann man da nun richtig klotzen (ILE) da bei der AS/400 sowieso alles dynamisch mittels Einspeicherkonzept verwaltet wird.
Klar muss man da in soweit aufpassen, dass man nicht die Systemgrenzen (Plattenplatz) sprengt :).
Hallo Peter,
m.E. sind diese Dinge heute zweitrangig.
Eine ernst zu nehmende Betrachtung über Entwicklungsaspekte würde sicher die leichte Lesbarkeit des Codes und die damit verbundene Verständlichkeit und Wartbarkeit in den Vordergrund stellen.
Bitte keinesfalls irgendwo 100 Byte einsparen und mit Tricks arbeiten, wenn dadurch die Lesbarkeit auch nur um einen Hauch verschlechtert wird.
Plattenzugriffe sollte man jedoch im Auge behalten. Hier kann durch Optimierung einiges beschleunigt werden.
Gruß
Herbert
... falls Du Material für eine Büttenrede bei der nächsten Informatiker Fassenacht suchst, kannst Du mal sehen, ob Du in der rpg400-l Mailingliste fündig wirst, da gibt es zuweilen noch Tipps von obigem Kaliber (call by reference is performater als call by value und das CONST nicht so funktioniert, wie man annimmt muss so sein etc...)
Ansonsten gilt die Devise: first make it right, then make it fast (wenn überhaupt nötig). Zeit wird verbrannt bei Dingen die Programme machen, die keiner haben will, oft sind Programme zu langsam, weil sie die vorhandenen Ressourcen nicht genügend auslasten. Eine der Ecken, wo man Optimierungs Potential hat, ist Datenbank- und Index Design.
D*B
es gibt literatur/kursuntrelagen wobei ich bezweifle ob die Tunningmassnahmen anno 1996 heute noch messbar sind. IBM Kurs OL93 aus 1996 AS/400 Inside copyright Fa. SOSY ApS. Wir haben intensive test mit div. RPG-Code durchgeführt und sind zu folgenden Ergebnissen gekommen: eine SCAN Operation ist 8-9 x schneller als LOKUP. ein MOVE/MOVEA in eine gesamte feldgruppe ist deutlich langsamer als ein MOVE in eine datenstruktur die die feldgruppe enthält. jede Feldgruppenoperation (auch OCCUR) ist deutlich langsamer als ein definiertes Feld. Alles erst messbar ab 100.000/1,000.000 wiederholungen !!! diverse Unterlagen sind verfügbar.
camouflage
20-06-12, 19:04
Und stimmt es heute noch, dass man interne Datenstrukturen möglichst kein halten soll, da die sonst zu viel Spieicher/Performance benötigen - habe gehört, dem wäre heute nicht mehr so, man kann also ruhig mal 100 oder 200 Stellen frei lassen, um für eine neue Variable die Datenstruktur nicht immer anpassen zu müssen und somit nicht immer alle Programm neu compilieren zu müssen....
Kannst Du mal verraten auf welchem Wissensstand (Release/Modell) Du bist...
Was heute immer noch was bringt, ist ein SETOBJACC auf Datenbankdateien direkt vor dem Aufruf eines Programms, das diese Dateien liest oder aktualisiert.
Außerdem sind die entsprechenden Befehle wie zum Beispiel DIV, MULT, SCAN, ... meist viel schneller als ein EVAL mit entsprechender Berechnung.
peterspeer
21-06-12, 06:34
Danke für Eure Antworten.
@Camouflage: Das ist ja das Problem, entwickelt wird auf V7, mit SQL und ILE usw. aber Infos über eben solche Dinge sind noch auf dem Stand 1999...da hat man sich mal über solche Dinge Gedanken gemacht.
Damals hies es auch jeder Read in RPG ist schneller als ein SQL-Fetch (auch das sollte heute wohl nicht mehr stimmen).
Das mit den Read-Operationen und dem Datenbank-design ist klar.
Aber ich hatte halt noch so im Hinterkopf, dass man eben auch Dinge wie Ihr schon genannt habt noch Effekt haben. (Ocur, Scan, Lokup, Move... was ist ggf. flotter...)
Aber das scheint ja nicht mehr so wirklich ausschlaggebend zu sein.
Nochmals Danke !
Gruß
Peter
... da machen sich Leute Gedanken darüber ob ein MOVE schneller als ein EVAL ist, und überlesen 100.000 Zeilen nur um einen einzigen Datensatz zu finden.
SQL Performance Analyse ist ein weitgefächertes Thema, zu dem es durchaus viele Artikel und Redbooks gibt.
Hier einige Links wo du fündig werden kannst:
Redbooks - SQL Performance (http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=SQL+AND+Performance)
Online Information Center - Database Information Finder (http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzatd%2Frzatdfinder.htm)
Birgitta
Damals hies es auch jeder Read in RPG ist schneller als ein SQL-Fetch (auch das sollte heute wohl nicht mehr stimmen).
Das wird immer noch stimmen, aber es geht auf neueren Maschinen heute eben alles viel flotter, und der Unterschied fällt deshalb meistens kaum auf.