home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20017 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!dtix!condor.navsses.navy.mil!system
  2. From: system@condor.navsses.navy.mil
  3. Newsgroups: comp.os.vms
  4. Subject: Re: ballooning EXE size
  5. Message-ID: <1992Dec29.141701.358@condor.navsses.navy.mil>
  6. Date: 29 Dec 92 19:17:01 GMT
  7. References: <01GSUT89O7JK000J0I@XRT.UPENN.EDU>
  8. Organization: NSWCCD, Naval Ship Systems Eng Sta, Phila PA
  9. Lines: 50
  10.  
  11. In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
  12. > I have a problem with the size of an executable going from ~1,000 blocks to 
  13. > something on the order of 75,000 blocks. 
  14. > 
  15. > What am I doing? I am charged with writing a small interface to some existing 
  16. > FORTRAN code. I have no control over the existing FORTRAN code and can only say 
  17. > that it makes extensive use of VAX-FORTRAN Structure/record/map statements. I 
  18. > don't own the large body of FORTRAN code and really don't relish the thought of 
  19. > rewriting it...
  20. > 
  21. > When the FORTRAN interface stub subroutines (e.g. subroutines that print a "not 
  22. > implemented" message and return) are replaced with my code, the resulting 
  23. > executable goes from ~1,000blocks to ~75,000 blocks. 
  24. > 
  25. > Yes, I use some scratch arrays (scratch arrays defined as local to the 
  26. > subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and the 
  27. > executable size when back to ~1,100 blocks. I presume the difference is due to 
  28. > my code size. Ok so far, but I can't get away with this for long....
  29. > 
  30. > Eventually, the addition of the simplest code causes the executable to go from 
  31. > 1,100 blocks to ~76,000 blocks. Looking at the LINK map, the size of my 
  32. > interface modules are quite small. Remember, this is FORTRAN and most of the 
  33. > memory is statically allocated.
  34. > 
  35. > $link/map/exec=foo.exe
  36. >  untouchable.olb/INC=foo_main, -    ! main calling routine
  37. >  untouchable.olb/L, -        ! library of untouchable code objects
  38. >  expm.olb/l, -            ! my interface routines
  39. >  sys$input/opt
  40. >    SYS$SHARE:FORRTL.EXE/SHARE,sys$library:vaxcrtl.exe/share
  41. > 
  42. > Thoughts? 
  43. > 
  44. What is the size of your arrays?  Do they contain pre-initialized data or are
  45. they just created as an array of zeros?  If the arrays do not contain data you
  46. should be able to for the linker to create the pages that are used to store the
  47. arrays as DEMAND ZERO pages.  DEMAND ZERO pages are created when the linker
  48. detects a region (default size: 5 pages or 2.5K bytes) in your program
  49. that contains un-initialized storage.  There are a few cases when a bug causes
  50. the linker to not compress a large range of uninitialized data to demand zero
  51. pages.  Fortunately you can control the linker's use of demand zero pages with
  52. a linker options file (see pages 3-7 and 6-19 of the VMS Linker Utility Manual
  53. V5.0).
  54. -- 
  55. Mike Jacobi
  56. NAVSSES VAXCluster system manager
  57. System@Eagle.Navsses.Navy.Mil
  58. System@Condor.Navsses.Navy.Mil
  59.  
  60. Disclaimer - I speak for myself.  No-one else.
  61.