kushmer@bnlux1.bnl.gov (christopher kushmerick) (04/06/91)
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. In the following, when upper case, PROGRAM means the pascal program ie program uses begin end. _Not_ the resultant executable. USES means uses in the turbo pascal sense. 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. In case 1 for each of the technojock units, there is only one ionstance of the statment USES tjockunit. In case 2, there are many. Now with an intelligent linking, I would think that this would not matter. Am I right. However I am currently using case 2, and it does seem to matter. Ie I am running out of memory. Perhaps my program is just to big. But before I go to the command line compiler and turbo debugger, I want to amke sure that there is not some simpler way tio decrease memory requirements. How much will I win by turning of debugging in some of the units? Local symbols? Thanks for listening. -- Chris Kushmerick kciremhsuK sirhC kushmer@bnlux1.bnl.gov <===Try this one first kushmerick@pofvax.sunysb.edu
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (04/07/91)
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
milne@ics.uci.edu (Alastair Milne) (04/09/91)
In <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. We have a large central unit too. I haven't counted for a while, but I believe it exports about 60 routines, and complex data structures. You can always tell, just by watching how long Turbo keeps compiling the one USES line, when it has reached this unit. >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. I don't know that there would be a significant difference. In both cases, all the units being used have to be linked in, and I usually find it's in the linking phase that Turbo runs out of memory -- even though I always use disc for linking. What might make a difference is overlaying some of them, if you can. Probably because the overlays get written out to a separate .OVR file, not to the .EXE . Now, try this: go back to the Turbo IDE, and compile again. When it gives you that hateful message that it's out of memory, *press F1*. If memory serves at all, you get a help screen talking about means of decreasing memory use. >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. But the linker still has to put it all together, and still has to handle all the symbols that every unit refers to. >Perhaps my program is just to big. But before I go to the command line >compiler and turbo debugger, I want to amke sure that there is not >some simpler way tio decrease memory requirements. Well, if you feel like living dangerously, you can turn off some of the runtime checks (stack, range, IO); but I prefer not to do this unless it's *really* necessary. >How much will I win by turning of debugging in some of the units? Local >symbols? *Lots* The debugger and the debugging info are very greedy. In Turbo 5.0, this made the difference for me between compiling relatively easily, and not compiling at all. Alastair Milne
hoffmann@infopls.chi.il.us (Robert Hoffmann) (04/10/91)
kushmer@bnlux1.bnl.gov (christopher kushmerick) writes: > Now with an intelligent linking, I would think that this would not matter. > Am I right. Chris, although intelligent linking *will* create a smaller EXE file, while the code is being compiled, all of the memory required by all of the called units is needed. To use your two examples: 1. USES only the actual units: the total memory of all units in the USES line is needed. 2. USES units which USE the actual units: the total memory of BOTH sets of USEd units will be needed during compilation. In other words, it's much more effective to USE units as straightforwardly (without nesting) as possible. To get a better idea, watch the "free memory" indicator in the Compile window while it's working. You'll notice free memory decrease steadily... then *increase* as unnecessary functions are removed from memory (and the compiled EXE file). Rob (who has no signature, but can be reached at hoffmann@infopls.chi.il.us)