Speicherplatz verschwenden durch Variablendefinition?

[dschroeder]

Hallo,
wir überlegen gerade, ob die beiden unten angegebenen Programmcodes sich im Speicherverbrauch unterscheiden. Die Routinen machen genau das gleiche. Aber die 2. Routine speichert das Rückgabeergebnis vor der Rückgabe noch in eine eigene Ergebnisvariable um. Das heißt, die 2. Routine hat eine Variablendefinition mehr. Aber meiner Meinung nach muss auch die erste Routine den Speicher 100000 "verbraten", da der Return das Ergebnis ja in irgendeinem Speicherbereich aufbereiten muss.

Dieter

dcl-proc test1;
dcl-pi *n varchar(100000);
dcl-s var1 varchar(50000);
dcl-s var2 varchar(50000);
... jetzt die Variablen mit Werten füllen ...
return var1+var2;
end-proc;


dcl-proc test2;
dcl-pi *n varchar(100000);
dcl-s var1 varchar(50000);
dcl-s var2 varchar(50000);
dcl-s ergebnis varchar(100000);
... jetzt die Variablen mit Werten füllen ...
ergebnis = var1 + var2;
return ergebnis;
end-proc;

[BenderD]

... wenn ihr aus den varchar char macht, spart ihr nochmal Speicherplatz, das ist zwar nicht viel, aber es läppert sich - und wenn man den gesparten Platz am Jahresende als Bonus ausgezahlt kriegt, kann da ein ganz schönes Sümmchen zusammenkommen.

D*B

[dschroeder]

Der Speicherplatz läppert sich bei uns tatsächlich, wenn man überlegt, wieviele Programme betroffen sind und wie oft diese von wie vielen Usern aufgerufen werden. Die Angaben oben sind ja auch nur ein Beispiel. Die Variablen könnten natürlich auch größer sein.

Ich persönlich finde die 2. Variante besser (lässt sich im Zweifel besser debuggen). Meine Frage geht ja nur dahin, ob dieses Verfahren den Speicherbedarf quasi verdoppelt?

Dieter

[AG1965_2]

Wenn man aus den varchar char macht, funktionieren diese Routinen aber nicht mehr.
Die lächerlichen Ersparnisse werden von denen, die ihre SQL-Statements mit zig %TRIMs zusammenstellen, zigfach wieder verbraten, D*B. :-)

[dschroeder]

Ich gehe mal davon aus, dass Dieter Benders Vorschlag eher ironisch gemeint war.

[Pikachu]

Welchen Speicherplatz meinst du und wo siehst du wieviel belegt ist?


Der Speicherplatz läppert sich bei uns tatsächlich, wenn man überlegt, wieviele Programme betroffen sind und wie oft diese von wie vielen Usern aufgerufen werden.

[dschroeder]

Ich meine den Hauptspeicher. Unsere Anwendung verwendet sehr viele "kleine" Tools, die immer wieder aufgerufen werden. Unsere Überlegung geht dahin, dass man die Hauptspeicherbelastung möglicherweise stark erhöht, wenn man "große Variablen" (Zeichenketten oder Arrays) übermäßig groß deklariert. Deshalb die Frage, ob das Umspeichern nochmal zusätzlich Speicher kostet.

Sehen kann ich die Speicherbelegung leider nicht direkt.
Ich tendiere selber eher dazu, ein Programm lieber lesbar zu schreiben anstatt auf das letzte Bißchen Performance oder Speicher zu achten. Trotzdem muss man ja nicht jede Deklaration übertreiben. Ich denke, dass würde auch unserer AS/400 irgendwann wehtun.

Dieter

[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 (http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzasd/sc092508557.htm%23drtnparm)

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