RE: ILE performance considerations

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

>If possible, do something about all those
>RNF7031 messages in the compiler listing.

I suppose this is because the system takes the time to initialise even the
unreferenced fields.  Food for thought.

-snip-

>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.

I haven't spent much time benchmarking applications that have been compiled
OPTIMIZE(*FULL).  Do you know how much does the optimiser moves object code
around?  I mean, if I carefully place the "read" and "parse" routines next
to each other in the source code, is it a guarantee that the object code
will be co-located?  Many moons ago I became proficient with $OLINK on S/3
because of severe memory constraints.  I sometimes wish there was a way to
tell the binder which routines I want co-located.

>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.

Are there any numbers for this?  I haven't got enough large service programs
to benchmark and can't spare the time at the moment to create a test suite.
I would have suspected that the cost to activate a single large service
program would be marginally less than activating a dozen smaller ones, but
I've had very satisfactory program startup times, even on an overloaded
model 510.  Given that, I put more weight on being able to manage the source
and objects.
  --buck