Litreatur iseries --> z. B. Performance

[Fuerchau]

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 .

[HerbertW]

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

[BenderD]

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

[E305GL]

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.