Re: ILE performance considerations

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

ý
Hello Nelson,

Since no one else as had a go at this, here are my thoughts:

>Am I correct in my assumption that there will only be one copy of code in
>memory at any one time, but many copies of the variables needed by each
>user?

Yes.  Commonly known as a reentrant program.  Code is shared even by jobs
running in different main storage pools.

>Should I be more concerned about streamlining the program's code size or
>the size of the variables that will be in use for each user?  Or perhaps my
>time would be better spent on trying to move even more functionality out to
>the procedures in the service program?

Both, probably.  If possible, do something about all those RNF7031 messages
in the compiler listing.  Code should be streamlined where doing so won't
obfuscate it.  However, simply moving it to a service program won't
necessarily help.  The service program should contain code that is used by
multiple programs.

>My first thought was to make separate programs out of each module and break
>the one big program down into many dynamic calls as we always did prior to
>ILE.  But if there is only one copy kept in memory anyway, I am not sure
>this would really improve anything over the one big program model.  How
>does paging work on a big program like this with many calls to internal
>modules, as compared to many smaller programs being called repeatedly?

Bound calls are faster than dynamic calls but the gain is probably minimal.
It depends on how frequently the routines are called.  If the separate
programs are called by multiple programs I would put them in a service
program.  If they are not then leave them as one program.  You will gain
management improvements by using separate modules but bind the single use
code into one program.  15MB is a bloody big program though, for what it is
worth I checked QSYS and found:

        8554 *PGM objects of which only 32 were over 1MB, only two were over
2MB, and the largest was 5.8MB.
        577 *SRVPGM objects of which 55 were over 1MB, only seven were over
5MB, and the largest was 13.7MB.

IBM do strip observability and fully optimize their shipped code which will
reduce space.

There is no appreciable difference in paging a section of a big program and
paging a small program.  The old guidelines of keeping frequently used
functions near the mainline and keeping routines that call each other
together are still valid and have an appreciable impact on performance.  Big
service programs take longer to activate than small ones and it appears that
a number of smaller service programs is better than one huge one both from a
performance point of view and a management view.

>Theoretical answers as well as real-world experience would be appreciated.

Is there a difference?

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»