ILE RPG

[kuempi von stein]

Hallo,

in den Handbüchern zu ILE wurde öfter mal drauf hingewiesen, dass es einen zeitlichen Unterschied gibt zwischen statischen und dynamischen call.
Nun frage ich mich wie gross denn der Unterschied ist bzw. ob das messbar ist ausser wenn ich mehrere tausend mal das gleiche aufrufe...?
Und dann zerbreche ich mir den Kopf noch über den Parameter "Optimize *FULL" im Debug Mode und generell ...
Ich vermute mal, dass durch mehrere Instruktionen gleichzeitig dann eben die Infos einer Variabel verloren gehen oder verfälscht werden können ...aber ... ist das wirklich die einzige Einschränkung? Oder gibt es da andere Pro/Contra die man genauestens abwägen sollte bei Verwendung/Nichtverwendung des Parameters?

Soviel erstmal

kuempi

[Fuerchau]

Naja, messbar ist so eine Sache.
Man bedenke:
Die Adresse eines externen Programmes wird bereits beim Start des Programmes ermittelt, wenn es per Konstante aufgerufen wird.
Je mehr Programme aufgerufen werden, desto länger dauert der Init.
Allerdings dauert ein Dateiopen erheblich länger.
Wird ein Programm per Variable aufgerufen, ermittelt RPG beim 1. Aufruf die Adresse des Programmes und verwendet dann immer diese Adresse bis die Variable mal geändert wird. Dann wird die interne Adresse zerstört und die Ermittlung wiederholt.

Beim ILE sieht es dann nicht so viel anders aus, ausser das eben Prozeduradressen ermittelt werden.
Wären diese Adressen statisch im wahrsten Sinne, würden LIBL-Suchen nicht funktionieren.

Adressen bleiben solange konstant, so lange das Programm in einer Aktivierungsgruppe aktiv bleibt. Es kann daher (eigentlich nur bei der Entwicklung) passieren, dass Adressen nicht mehr stimmen, wenn Programme gelöscht werden.

Nun kann man mittels CRTPGM-Befehlen ja laufende Programme ersetzen.
Die Befehle verschieben aber das aktuelle Programm in die QRPLOBJ und erstellen dann das neue Programm.
Alle aktiven Programme arbeiten daher mit dem ALTEN Programm weiter !!!
Dies ist sehr schön im Aufruf-Stack zu beobachten und führt mitunter zu seltsamen Ergebnissen.

Was die Zeit dann so angeht, so ist diese absolut zu vernachlässigen. Ein Call dauert dann nicht viel länger als ein EXSR.
Nur beim 1. Aufruf werden halt Inits durchgeführt (*INZSR).

Mit dem berühmten *INLR kann man allerdings einiges an Performance kaputtmachen.
*INLR=*ON: das Programm wird deaktiviert und alle Adressen gelöscht incl. Dateiclose.
*INLR=*OFF: der Status incl. Adresse bleibt erhalten und der Init gespart.

Was den Optimize angeht, so rekompiliert dieser das Programm, da die MI-Quelle (allerdings nicht lesbar) im Programm steht.
Da nun mal jede CPU Register hat, versucht der Optimizer nun verschiedene Befehle auszutauschen (Variable in Register, Typkonvertierungen) als auch Schleifenoptimierungen.
Das Ganze bringt tatsächlich nur Vorteile, wenn mehrere tausend Durchläufe innerhalb des Programmes passieren.
Allerdings: man bedenke, dass das Programm ja durchaus sooft läuft, zwar nicht sofort aber über mehrere Job's und den Tag verteilt. Es kann also durchaus zu günstigeren CPU-Verwendungen (DSPJOB, Jobausführungsattribute, Benutzte CPU-Zeit) kommen.

Aber wie immer, was die Performance angeht: Das ist die allerletzte Stellschraube an der man drehen kann. Meist ist es sinnvoller, sich die Programme selber anzusehen, Zugriffe zu optimieren (lieber CHAIN als SETLL/READE) usw.

Übrigens: Nach CHGPGM ... RMVOBS(*ALL) ist ein Optimize nicht mehr möglich. Das war übrigens früher auch ein Problem beim Umstellen CISC zu RISC udn wer weiß, ob das nicht bei irgendeiner Version wieder mal gebraucht wird.

Das gesamte OS arbeitet mit zigtausend Calls. Um die Geschwindigkeit zu verbessern gibt es ein internes Systemobjekt QINSEPT.
Dieses ist eine Adresstabelle aller relevanten Systemprogramme, die beim Installieren des BS erstellt wird.
Das BS arbeitet daher nicht mit CALL 'PGM' sondern mit CALL QINSEPTPTR(ID_PGM). Dadurch wird der Init erheblich beschleunigt.

[BenderD]

Hallo,

im durchschnittlichen RPG-Ham fast ohne jede Modularisierung ist das völlig ohne Bedeutung. ILE ist entwickelt worden für C und insbesondere C++ Programme (in diesen Sprachen sind mittlerweile weite Teile des OS geschrieben). C++ Programme sind weitaus höher modularisiert als sich das der durchschnittliche RPG Programmierer traut (Procedures mit einer Anweisung sind durchaus nicht ungewöhnlich; hundert Anweisungen sind schon extrem viel!!!) solch feine Modularisierung hat tief gestaffelte Aufrufstapel mit tausenden von Aufrufen, da zählt dann der Unterschied.
Wenn man Monolithen in ILE schreibt (ich habe Anwendungen gesehen mit SRVPGM1 und später gab es dann ein zweites), dann werden die initialen Ladezeiten zum Problem.
Was an ILE wirklich gut ist, ist die bessere Lesbarkeit durch feinkörnigere Modularisierung, wenn man das denn nutzt.
Zum Optimize noch: immer wenn man nicht sagen kann ob man es klein oder schnell haben will, sollte man eher die Finger davon lassen.

mfg

Dieter Bender

Hallo,

in den Handbüchern zu ILE wurde öfter mal drauf hingewiesen, dass es einen zeitlichen Unterschied gibt zwischen statischen und dynamischen call.
Nun frage ich mich wie gross denn der Unterschied ist bzw. ob das messbar ist ausser wenn ich mehrere tausend mal das gleiche aufrufe...?
Und dann zerbreche ich mir den Kopf noch über den Parameter "Optimize *FULL" im Debug Mode und generell ...
Ich vermute mal, dass durch mehrere Instruktionen gleichzeitig dann eben die Infos einer Variabel verloren gehen oder verfälscht werden können ...aber ... ist das wirklich die einzige Einschränkung? Oder gibt es da andere Pro/Contra die man genauestens abwägen sollte bei Verwendung/Nichtverwendung des Parameters?

Soviel erstmal

kuempi

[kuempi von stein]

Vielen Dank für diese Ausführungen ...

schönen Tag noch

kuempi