Der eigentliche CALL ist von der Performance absolut egal, ob Programm oder Procedure.
In beiden Fällen wird ein Instruction-Pointer verwendet.
Entscheidend ist da eher die "Initialisierungszeit" eines Programmes bzw. Serviceprogrammes.
Jede konstante Verknüpfung zu einem Programm/Procedure wird beim ersten Aufruf des Programmes initialisiert.
Hierzu wird das Objekt gesucht und der Einsprungspunkt ermittelt.
Je mehr Call's also im Programm stecken, desto mehr Objekte müssen ermittelt werden.

Bei Prozeduren ist es ein wenig anders.
Es kommt i.W. darauf an, wieviele verschiedene Serviceprogramme denn durch die Prozeduren benötigt werden.
Das ermitteln des Serviceprogrammes dauert genauso lange wie beim OPM-Programm.
Die Prozedurpointer werden dann allerdings über die exportierte Liste der Funktionen an Hand des internen Indexes zur Verfügung gestellt, also 1. Funktion = Index 1, 2. Funktion = Index 2, usw.
Dies erklärt im Übrigen auch, dass bei Neuerstellung eines Service-PGM's ohne BindaryLanguage mit eigener Signatur, sich diese Indizes auf Grund der Sortierung nach Namen verschieben können.

Stellst du also viele Funktionen über diverse OPM-Programme zur Verfügung dauert der Init letztlich länger als bei vielen Funktionen über wenige Serviceprogramme.
Ein paar Microsekunden kannst du per "CALL VARIABLE" gewinnen, da dann der Pointer erst beim ersten Aufruf besorgt wird. Solange sichdie variable dann nicht ändert bleibt der Pointer erhalten.
Das selbe kannst du mit Dieters "dynamschen Prozeduraufruf" erreichen.
Allerdings verlierst du dann Informationen für DSPPGMREF.

In der Gesamtbetrachtung einer Anwendung sind das Stellschrauben, die dir beim Programmstart letztendlich Microsekunden bringen werden.
Da sind eher andere Initialisierungen wie laden von Anwendungsparametern, Initialisierungen mit ungünstegen SQL's usw. viel entscheidender.

Anwendungsdesign mit Serviceprogrammen und Prozeduren bringen ansonsten erhebliche Vorteile.