RE: ILE performance considerations

Thanks for your comments, Simon.  I was starting to wonder what had happened
to all the ILE proponents out there.

A couple of interesting results came up when I reworked all the internal
modules (contained in the 15 meg program) to a state where they could be
called dynamically as separate programs.  First, I ended up with 12 compiled
programs that totaled up to only 13.6 megs.  I had to rearrange a few things
that had previously been handled as exports/imports between the modules into
a datastructure passed by a pointer.  I guess this is where the savings came
from.  Then, just for kicks, I recompiled all the modules back into the
single program again, and the new program came out to only 12.2 megs.  With
Debug at *NONE and Optimize at *FULL. it reduces on down to 4.3 meg.  At
least I got it under IBM's largest one :-).  Further tinkering here probably
won't gain that much more.

I still have over 500K in static storage to deal with though, so I think I
need to put more effort on reducing that side of things, now.  As a combined
program, I assume each user will get all 500k allocated to them each time
they call the program.  If I use the 12 program model, only 4 programs would
always be called and the other 8 would be called less frequently (this fits
the 80/20 rule fairly well).  If the first user (or some user) has all 12
programs active, will each additional user that calls, say, the first
program only get only the variables associated with the first program or all
500k?

Another question:  The initial call to this system is to a cl program that
runs in *CALLER and saves everything (libr lists, lda, etc) about the
caller's environment and then calls this program(s) which run in their own
named activation group.  On termination, the cl reclaims that activation
group and restores the caller's original environment.  If a second user, in
another job, is using the program code reentrantly (is that a word?), what
will happen when the first user's job tries to kill the activation group.
Will the rclactgrp command be ignored because some other job is using the
code?  I guess I don't understand the relationship between the program code
in an activation group, which is part of a job, and the other user's use of
that same code in memory.  Does each user's activation group only contain
pointers to the code and not the code itself?  If so, I guess blowing away
one activation group would not effect another user's activation group that
is using the same code. Is this the way it works?

When I broke up the one program into 12 separately compiled programs, I gave
them each their own activation group name with the thought that I could
reclaim the lesser used ones when the user was finished with it and,
thereby, keep the total size down.  Do you think this is still a good idea?

Thanks for your help.




************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************