RE: Affect of program size on memory usage

Hi Darren,

I'll take a shot at this... I believe this falls back to how SLS
(single level storage) manages objects. There will only be one copy of
the program object in main storage at one time. Potentially many JOBS
can invoke that program object. All memory allocations for that program
occur at run time, so that storage for this program is local to each JOB
that is running the program.

The actual size of the program object doesn't impact the system as much
as the amount of storage to be initialized. Moving static globals to
local may not improve performance, since local variables must be
allocated and initialized each time the procedure is invoked. In the
global/static realm, the allocation only occurs once...

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx
Sent: Monday, November 16, 2009 8:53 AM
To: midrange-RPG RPG message board
Subject: Affect of program size on memory usage


I've taken some pride in reducing static storage by moving variables to
local subprocedures, which also makes the code more readable too.
However,
I often see the size of the program itself grow by much more than the
storage reduction. I use DBGVIEW(*LIST), so I'm fairly certain that as
I
add more source lines, my program object grows quickly in size. SQL
also
takes a toll as it adds access path information when the program is
first
executed.

My question is, does the system i load the whole program object into
memory, or is their some intelligence there? If so, is there a way to
compare the real program object size, minus the source view?