From: "John M. Aldrich" Newsgroups: comp.os.msdos.djgpp Subject: Re: Size of executable in memory? Date: Wed, 26 Mar 1997 06:50:41 -0800 Organization: Two pounds of chaos and a pinch of salt Lines: 81 Message-ID: <333937C1.7075@cs.com> References: Reply-To: fighteer AT cs DOT com NNTP-Posting-Host: ppp220.cs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Andy Eskilsson wrote: > > How memory much does the executable take?? Uh fuzzy question :-) *sigh*. It's one of those wonderfully vague things that is impossible to predict just from the size of the executable. ;) The DPMI host itself runs in conventional memory. For CWSDPMI, this is about 70k for the first invocation, and 18k for each child program. For Windows, it's about 18k per program. For other hosts like QDPMI, it's a _lot_ more. (DOS4GW needs over 200k...) This memory includes the transfer buffer. See the DJGPP FAQ, chapter 15.8, for lots of information on this issue. The amount of virtual memory used is based on several things. First, the program's code is itself loaded, but only those segments that are actually in use. If you fiddle with the linker script to get it to stick extra segments onto your code, those are _not_ loaded in unless you access them. Second, the startup code allocates all static variables. If you put a 2 MB static array in your code, it won't be part of the executable, but it will take up memory when the program is run! Third, any dynamic structures needed by the DJGPP startup code must also be allocated. This includes the environment, command-line arguments, internal file structures, etc. Then you have to count anything you allocate yourself. The only real way to tell how much memory a program takes is to take "snapshots" of the physical and virtual memory available both before and after it is run. To do this, you must first be in plain DOS. Windows does so many wierd things to memory management that this technique is totally unreliable there. Run "go32-v2" immediately before running your program, and record the values it shows. Then run your program and allocate anything you need to allocate. Be sure that you actually access this memory, so it is paged into RAM instead of left "floating." Do NOT free any memory! Then have your program check _go32_dpmi_remaining_virtual_memory(). Hopefully this number will be less than the sum of physical and virtual memory reported by go32-v2, and will therefore represent the amount of memory taken up by your program. > The question is now, how much extra space in memory does a 1-meg > 'unstripped' executable take, compared to the same executable, > stripped to 499k? None. The debugging code that 'strip' removes is never loaded into memory; it's just raw text data that gets stuck onto the end of the executable. Stripped or compiled for maximum debugging, your programs will take up the same amount of memory at runtime. > Exactly what is it strip removes (well I don't have -g enabled and -O2 > as optimization, so it shouldn't be debug-info..) and (probably the > real question is:) does this take extra memory? Strip removes all the symbol information from your program. Even if you don't compile with '-g', your code still stores the names of functions and other static objects, so that a debugger such as 'symify' can produce a meaningful stack traceback. Using the extra debugging levels merely adds additional information that allows debuggers to do more with your program. > If it isn't used soo much, it might not matter if it can be swapped > out, but life isn't always so simple or? It's never used, and is never read in. Having it only makes a difference to the amount of disk space your program takes. :) > I am messing around with DLM and python, managed to compile it, and > get it up running, but the binary is 606k, and I also need to load > DLMS (object-code?) in the size of 147+300k.. well this sums up to a > megabyte.. Can't strip it, and I wonder if it is worth these 500k's > having dynamic loading? You could always try packing the executable with the DJP executable packer. I don't know if this is compatible with DLMs though... -- --------------------------------------------------------------------- | John M. Aldrich, aka Fighteer I | fighteer AT cs DOT com | | Descent 2: The Infinite Abyss - The greatest Internet game of all | | time just got better! This time, you're going all the way down...| ---------------------------------------------------------------------