Mail Archives: djgpp/1997/03/27/13:37:45
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...|
---------------------------------------------------------------------
- Raw text -