Article 62350 of comp.os.vms:
Path: jac.zko.dec.com!pa.dec.com!decwrl!tribune.usask.ca!rover.ucs.ualberta.ca!unixg.ubc.ca!nntp.cs.ubc.ca!bcsystems!ewilts
From: ewilts@vmsmail.gov.bc.ca (Ed Wilts)
Newsgroups: comp.os.vms,comp.lang.fortran
Subject: Re: FORTRAN oddity
Message-ID: <1995Jun5.215818.6685@venus.gov.bc.ca>
Date: 5 Jun 95 21:58:18 PDT
References: <1995Jun5.153907.1565@nrlvx1>
Reply-To: EWILTS@GALAXY.GOV.BC.CA
Organization: BC Systems Corporation
Lines: 68
Xref: jac.zko.dec.com comp.os.vms:62350 comp.lang.fortran:18615

In article <1995Jun5.153907.1565@nrlvx1>, koffley@nrlvx1.nrl.navy.mil ("JOE KOFFLEY") writes:
> I'm posting this for some of our astro guys here who have asked me to look into
> an anomaly they are experiencing trying to compile and link a rather large
> FORTRAN program. Without going into too much detail the symptom is as follows:
> 
> They've noticed that the addition of this one subroutine has
> caused the .exe size to go from something like 6000 blocks to 24000 blocks.
> I suggested moving the  position of the subroutine in the linking sequence
> to the top of the routines listed in their link command and lo and behold
> the size comes back down to about 6000 blocks !
> 
> The subroutine in question passes nearly all of it's arrays (some multi-
> dimensional and most real*8) as calling args with very few arrays in the
> common blocks.

I'm attaching an article that Steve Lionel posted back in '92.  It helped me
back then when I saw the same problem (thanks Steve!).  I'm sure it's still
useful, and there is a DSNlink article entitled "Image File Grows Much Larger
After Adding Small Amount of Code" in the OpenVMS database that basically says
the same thing.  It will direct you to the LINKER manual for more details.

I hope this helps.

--- Steve's article ---
A number of people have replied to Loren Buhle's question about "Balooning
EXE size" with the suggestion to increase the linker's cutoff point for 
creating new demand-zero image sections using the ISD_MAX linker option
statement.  Though that "fix" often will shrink the image size, it has a hidden
cost; the reason for the limit in the first place.

As the number of image sections grows, the image activation time also grows;
an image with 100 or more image sections can take a long time to activate.
Sometimes this isn't a problem, but sometimes it is.  The ideal solution, which
I described in my previous posting, is to reduce the number of image sections to
the absolute minimum by using the linker COLLECT option statement.  If possible,
get it down such that there are no two image sections of the same type
(read-only, demand-zero, copy-on-ref, etc.).  I would only recommend adjusting
ISD_MAX if you haven't succeeded using the COLLECT method.

Some additional tips - use COMMON instead of large local variables; even a 
COMMON which is only used by one routine.  Each COMMON has its own PSECT name 
and thus you can use COLLECT to put all the uninitialized COMMONs together.
Reserve local variables for non-arrays and initialized storage.  Even better,
put all your data-initialized storage into their own set of COMMONs and 
COLLECT them into their own image section.  The VAX FORTRAN and VAX FORTRAN-HPO
Release Notes contain additional details on how to use COLLECT in a linker
options file.

At present, there is a limit of 250 named COMMONs in VAX FORTRAN, and no way
to allocate arrays on the stack (which would be ideal for large local arrays).
In DEC Fortran for OpenVMS VAX V6.0, which we expect to be shipping by March,
this limit is raised to 508, plus you can allocate arrays on the stack by
using the AUTOMATIC statement.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062

-- 
Ed Wilts, BC Systems, 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA     Office:  (604) 389-3430   Fax: (604) 389-3412

Disclaimer: The opinions and statements contained in this posting are the sole
responsibility of the author and have not in any way been reviewed or approved
by my employer or any network service.


