Why does declaring a 100 MB zero-initialized static array not add 100 MB to the program image on disk?

## Two static regions, one lifetime Variables that live for the whole process - not per call, not per allocation - are described in the program image and mapped by the loader before the first instruction runs. They land in one of two regions, and which one depends on a single question: **is the starting value all zeros?** | | Initialized static data | Zero-initialized static data | |---|---|---| | Starting value | any non-zero pattern | all zeros | | Carried in the image | the actual bytes | size and symbols only | | Effect on file size | grows by the data size | negligible | | Supplied at load by | copying or mapping the image bytes | a zero-filled range | | Lifetime | the whole process | the whole process | | Writable at run time | yes | yes | Both regions behave identically once the program is running. The distinction exists entirely to keep the file small. ## Why zeros are not worth shipping The image is a description of what the map should look like at entry. For a region whose contents are an arbitrary pattern, the only possible description is the pattern itself. For a region whose contents are all zeros, the pattern is implied by a single fact - *it is zeros* - so recording a size is a complete description. Storing 100 MB of zero bytes in a file and then reading them back would be pure ceremony: the same result, at the cost of 100 MB of storage and the time to transfer it. At start-up the loader therefore does this: 1. Reads the description of each region from the image. 2. Maps the initialized static data so it holds exactly the bytes the image carries. 3. Maps a range of the recorded size for the zero-initialized data, guaranteed to read as zeros. Step 3 is also a correctness guarantee, not only an optimisation: the program may rely on those variables starting at zero, so the range must be zero-filled rather than whatever was previously in that memory. Handing a process another program's leftover bytes would be a serious information leak as well as a bug. ## What it does not make free Three things the trick does *not* buy, worth saying explicitly because they are the follow-up: - **Address space.** The region occupies its full declared size in the map from the moment it is mapped. The array is 100 MB wide as far as addressing is concerned. - **Physical memory as it is used.** Touching the array has a real cost in hardware memory. Exactly how the operating system backs a mapped range and accounts for it is a separate subject with a separate owner; the point here is only that a small file does not imply a small running process. - **A different lifetime.** It is still static data: it exists from load until the process exits, whether or not anything ever reads it. There is no reclamation of a region like this while the program runs. ## Reading a footprint with this in mind This is the reason image size is a bad proxy for memory footprint in both directions. A tiny file may map a very large zeroed region; a large file may be almost entirely instructions and constant tables, whose mapped cost is shared across every process running that program. If you want to know what a process will occupy, read the regions in its map and their sizes - never the size of the file it came from. The same reasoning explains a related observation: a large lookup table filled with meaningful values genuinely does enlarge the image, and is a legitimate size trade to notice. A large table that is computed at start-up and merely declared zero does not, which is sometimes why one design ships a much smaller artifact than another with identical run-time behaviour. ## Where the boundary of the trick is It applies only to storage the program declares at **build** time. A 100 MB block requested at run time was never described in the image at all, so there is nothing there to shrink. The build-time split is precisely what makes the question askable, and it is also why a program that moves a large table from static declaration to run-time construction changes its file size and its start-up behaviour but not necessarily its peak footprint.