Newsgroups: comp.lang.pascal Path: utzoo!utgpu!watserv1!maytag!watstat.waterloo.edu!dmurdoch From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch) Subject: Re: Turbo pascal question on memory requirements Message-ID: <1991Apr7.044644.14516@maytag.waterloo.edu> Sender: news@maytag.waterloo.edu (News Owner) Organization: University of Waterloo References: <1991Apr6.150859.9694@bnlux1.bnl.gov> Distribution: na Date: Sun, 7 Apr 1991 04:46:44 GMT Lines: 57 In article <1991Apr6.150859.9694@bnlux1.bnl.gov> kushmer@bnlux1.bnl.gov (christopher kushmerick) writes: >I use a large subroutine library for the front end of programs that I write. >(If interested it is technojock turbo toolkit - quite good). I have a question >which is motivated by the fact that in my AT with no ems, my programs quickly >run out of memory inside the integrated environment due to the fact that I >use 8 moderatly large size units just for the aforementioned front end. > >Ok. Here we go with the question. > >Which would we expect to take more memory: > >A program which > >1: USES all of the technojock units. > >2: A program which itself does not use the technojock units, but which uses > my own units where all of the work is done, and which in turn > use the technojock units. > > >In case 1, all of the work is done by procedures in the program. In case 2, the >work has been split up into logically separate units. In case 2, the program >is just a caller loop and knows nothing about, for example, the technojock >stuff. I think that the actual code in the units doesn't matter to the compiler so much as the number of symbols it has to keep track of. The code is only in memory during the compiling of one unit; the symbols have to hang around for all of them. If this is actually true, then probably #2 is worse: it has the variables in your units to keep track of, which it doesn't have in #1. (Of course, if your alternative is to make the program a huge file containing everything that would have gone into the units, this may not apply.) >How much will I win by turning of debugging in some of the units? Local >symbols? Both are worth a lot, in my experience. Things to try (from the back of my Object Professional manual): - compile to disk, not to memory - set the link buffer to disk - turn off range and stack checking in debugged units - turn off debugging and local variables in debugged units - remove unnecessary TSRs before starting TURBO/TPC - use TPC instead of TURBO - extract all units except something tiny like PRINTER from TURBO.TPL (i.e. create SYSTEM.TPU, DOS.TPU, etc.) - keep your main as small as possible (hey, I was wrong! -djm) - move as many declarations as possible from the Interface section to the Implementation section in your units I hope this helps. Duncan Murdoch dmurdoch@watstat.waterloo.edu