27 Aug
2001
27 Aug
'01
6:28 a.m.
Iggy Drougge wrote:
I'd agree, you are old fashioned. Size of an executable does not represent
it's memory usage, but it's disk usage. Based upon what I see for Solaris,
that 1MB hello_world will use about 24K of memory when run. That's still
excessive because it's statically linked. By statically linking
the programmer has ensured that there will be two copies of all of the
library routines needed to run that bit of code in memory simultaneously.
(There are systems that are exceptions to the rule and won't multiply map
identical pages.)
On an OS that supports virtual memory, all the portions of the library that
support start up, printf(), and exit() are already going to be in memory
because some other program is already using them. Trying to save bytes by
writing your own "low memory" printing routines, you waste space. It's
like
not using routines in your Apple ]['s ROM because you could write your own
smaller ones. It's not like you're going to free up any ROM space.
Remember my 40-some byte linux hello world that was in a 300-something byte
file? It's memory usage is 8K+system overhead. (One page code space, one page
data (stack) space). Would have been 12K if I hadn't stored the string in
code space. The system overhead is significantly larger than 8K.
I'm not disagreeing that it is the programmers job to make his code as memory
efficient as possible. I just think that the job is a bit different than
what you might expect. Memory efficiency in a VM OS is an attempt to keep the
minimum resident working set. Using existing widely used shared libraries
(libc, libm) is part of it. Not doing linear searches through large data
structures to find a single data item is part of it. Using memory mapping to
access large files is part of it. Keeping your non-resident set small isn't
really that useful unless you are also disk storage constrained.
On a non VM system, fighting for every byte, and replacing library routines
is OK. On a VM system, be nice to the VM subststem and it will be nice to you.
Eric
So what's
your point? How much memory do you have on this machine? What
fraction of main memory is 932,131 bytes? Given dynamic linking, what
fraction is 11,811 bytes? The PC tools live on big memory machines, there
is no motivation to make them small. On my 68HC11 cross compilation system
compiling hello.c gives me 210 bytes. If it gave me 11K bytes I'd throw it
out because the most I can work with is 64K and 11K is too much to spend on
printing a string.
I may be old-fashioned here, but I'm of the opinion that my expensive and
valuable memory should be available for my leisure, not wasted by lazy
programmers with lousy compilers. How much memory I may have is my business,
the programmer's business is to make sure that as little as possible is wasted
on applications when it could be used for data or other applications.