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.