Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!petera
From: petera@utcsri.UUCP (Smith)
Newsgroups: net.lang.c
Subject: The cost of large uninitialized static/global arrays
Message-ID: <2810@utcsri.UUCP>
Date: Wed, 21-May-86 16:41:50 EDT
Article-I.D.: utcsri.2810
Posted: Wed May 21 16:41:50 1986
Date-Received: Wed, 21-May-86 16:42:35 EDT
Distribution: net
Organization: CSRI, University of Toronto
Lines: 43




     If you are programming in C and are worried about the size of
your executable file and the time required to load this file off disk
ie as with an editor or other frequently used utility, consider a
reasonably large C program with a declaration of a global or static
array which is pretty big relative to the size of the executable 
program. For example consider a program of around 80K with a 64K
array declared but uninitialized until run time eg: something like:

     char *bigarray[16384];  

     Depending on the linker/loader/compiler we may end up with the
executable program occupying 80K+64K on disk. Where 64K of the disk 
space is NULL. Hence everytime we execute it, it takes nearly twice
as long to load off disk! And, what does it do during that time? It loads
NULL's into memory! What a complete waste of time and space. Especially
if you are executing the program frequently, nearly half of the load
time is wasted, not to mention nearly half the space occupied by each 
copy of the dormant executable file. 

     While this may be obvious to many experienced assembly language
programmers, it may not be obvious to other programmers. I had learnt
the lesson while programming in 8080 for my old H-8 where memory and
disk space were scarce but had completely forgotten about it because
of the large amount of memory now available on most machines. It only
just hit me again when I happened to look at a uuencoded copy of one of my 
programs. The uuencoding was nearly all blanks ie compressed NULLs.

     Some compilers/linkers/loaders may avoid this problem by not 
storing large uninitialized static/global data in the executable 
file, but rather expanding it at load time. In the case of MS-DOS
this appears not to be done. So, the lesson learned is to allocate
your large uninitialized static/global space at run time and then
you do not have to worry about how smart the loader is. This is
probably one major factor why some C programs compile to a large 
executable file on one machine but to a significantly smaller file
on another.

     Peter Ashwood-Smith
     University Of Toronto.