Speicherplatz verschwenden durch Variablendefinition?

[dschroeder]

Nochmal zur Erklärung: Ich habe lange Jahre die Philosophie vertreten, dass Hauptspeicher auf der iSeries kein Problem darstellt, welches man als Programmierer beachten müsste. Aber vor ein paar Jahren hatten wir mal ein Problem in einer Copy-Strecke, die in fast jedem Programm vorhanden ist. Dort hatten wir große Datenstruktur-Deklarationen drin und vergesse, die Strukturen als Template zu deklarieren. Das heißt, jedes Programm, das die Copy-Strecke verwendet hat, hat den Speicherplatz für die Datenstrukturen der Copy-Strecke alloziiert. Das haben wir zunächst gar nicht gemerkt. Aber irgendwann mussten wir mal die gesamte Anwendung durchkompilieren. Danach drehte sich auf der Anlage fast nichts mehr, weil der Hauptspeicher völlig zu war. Nachdem wir die Struktur in der Copy-Strecke auf Template gesetzt haben und alles neu kompiliert hatten, lief es wieder wie geschmiert. Das heißt, auch bei einer iSeries muss man grundsätzlich auf den Speicherverbrauch achten.

Dieter

[andreaspr@aon.at]

Ab 7.1 kann bei der Return-Definition einer Prozedur das Schlüsseltwort RTNPARM angegeben werden.
Dieser soll die Performance spezielle bei größeren Rückgabewerten erhöhen.
RTNPARM

lg Andreas

[BenderD]

@varchar oder char: selbstredend geht das auch mit char. Das ist ein prototyped call, der nicht einmal exportiert wird, wo ist da das Problem (RTFM)

@Speicherverbrauch: in Deinem Beispiel geht es um lokale Variablen und die sind automatic storage, werden also zur Laufzeit allokiert und leben bis zum Ende der Prozedur. Physilaisch werden sie vom Heap des Prozesses geholt und da zählt nur die maximale Größe => Platz kostet das also nur bei denen. die zum Maximum beitragen (Rekursion, tief verschachtelte Procedures jeweils mit viele automatic storage) das kostet allenfalls Zeit zum allokieren und initialisieren des Speichers.

@Speicherverbrauch: Bei der Copy Strecke kommt es wieder drauf an, wo die drin steckt. Wenn die im globalen Teil des Moduls steckt und man gleichzeitig ein krummes Modul Design hat (z.B.: viele ein procedure Module) und auch noch mit den Activationgroups krause Dinge veranstaltet, dann kriegt man da vielleicht Probleme hin. Problemkandidaten sind auch statische Riesenarrays, die kosten Zeit und Platz, was noch schlechter ist.

Resumee: bei Beachtung einiger weniger einfacher Grundregeln im modularen Design ist Speicherplatz kein Faktor um den man sich besonders kümmern müsste. Vernünftig eingesetzt ist es besser der Büchse ein wenig mehr Speicher zu gönnen und ihn bei der Programmierung sinnig einzusetzen. Ansonsten gilt: wo kein Problem feststellbar ist (Laufzeit, Skalierbarkeit) versucht man auch nicht das nicht vorhandene Problem zu lösen.

D*B

[dschroeder]

Erstmal Danke für die vielen Antworten und Tipps. Meine konkrete Frage, ob die beiden Procedures unterschiedlich viel Hauptspeicher (temporär natürlich, eben solange die Routine läuft) benötigen, konnte scheinbar niemand beantworten. Ist wahrscheinlich auch gar nicht so einfach.
Ich entnehme dem ganzen aber, dass Speicher durch lokale Variablen kein besonderes Problem darstellen sollte, da er ja immer nur kurz gebraucht und dann wieder freigegeben wird. Also brauchen wir da nicht zu knausern.

Dieter

[Fuerchau]

Auch bei Returnwerten ist das eher unkritisch da sie auf dem Stack angelegt und nach der Zuweisung wieder verworfen werden.
Sicherlich muss ein "Return Wert" das Ergebnis auf dem Stack ablegen.
Da lokale Variablen im automatischen Speicher liegen muss dieser Wert ja "gerettet werden" um nach oben weitergegeben und wieder zerstört zu werden.
In obigem Bespiel ist der Effekt eigentlich egal, da in beiden Fällen identischer Platz verbraten wird.
Ein "Return Var1 + Var2" legt ein Zwischenergebnis an, das dann durch den Return wieder kopiert werden muss. Das Zwischenergebnis kann man natürlich auch selber anlegen und der Return kopiert dieses dann wieder.

Sehr große Zwischenergebnisse bewegen auch tatsächlich viele Bytes und zwar unabhängig davon, ob bei Varlen-Feldern alles gebraucht wird oder nicht.
Der Type Varlen (egal ob SQL oder RPG) wird nur durch Laufzeitroutinen und nicht native durch MI unterstützt.
Das Feld wird nämlich immer bis am Ende mit Leerzeichen aufgefüllt!
Dies kann man sehr schön im Debugger sehen (X-Ausgabe) oder in COBOL.
Nach der Zuweisung eines kurzen Wertes in die Variable, die vorher länger gefüllt war wird der Rest des Feldes tatsächlich initialisiert!
In COBOL wird tatsächlich eine Struktur mit der Länge (4-Byte COMP-4) und dem Inhalt definiert. COBOL unterstützt den Typ nicht native, man muss das Feld füllen und die Länge anschließend selber ausrechnen. Genau dies macht die Runtime von SQL und RPGLE.
CHAR-Felder sind also auch schneller als VARCHAR-Felder.

Man sollte sich also schon überlegen, ob Routinen dieser Art vielleicht besser die Ergebnisfelder exportieren und somit statisch anlegen. Jeder Caller ist für die schnelle Entsorgung des Ergebnis sowieso verantwortlich und Returnwerte mit 16MB sollten sowieso vermieden werden.

[BenderD]

Meine konkrete Frage, ob die beiden Procedures unterschiedlich viel Hauptspeicher (temporär natürlich, eben solange die Routine läuft) benötigen, konnte scheinbar niemand beantworten. Ist wahrscheinlich auch gar nicht so einfach.

... selbstverständlich lässt sich diese Frage leicht beantworten, das ist nämlich elementar: das braucht automatic storage, schmälert also das Weihnachtsgeld, wenn man danach bezahlt wird; ob sich das auf den Speicherverbrauch des Jobs insgesamt auswirkt, hängt von den anderen Programmen in der Historie des Jobs ab. Das kann man sich so vorstellen, dass es egal ist, ob ich bei meínem Bierglas einen halben Liter nachfüllen lasse, wenn es leer ist, oder einen viertel, solange das erste Glas, das ich bestellt habe, ein Liter Fassunsgvermögen hatte!

Na denn Prost

D*B

[dschroeder]

Nochmal vielen Dank für alle Antworten.
(Weihnachtsgeld gab es glücklicherweise bereits. Deshalb können wir den Speicher jetzt voll ausschöpfen.)
Dieter