Xref: news-dnh.mv.net comp.os.msdos.djgpp:3764
Path: news-dnh.mv.net!mv!news.sprintlink.net!newsfeed.internetmci.com!in1.uu.net!noc.near.net!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!rice!news!sandmann
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: decreasing program loadup time in V2
Date: Sat, 09 Dec 1995 23:09:45 CST
Organization: Rice University, Houston, Texas
Lines: 16
References: <DJBvn0 DOT Avo AT jade DOT mv DOT net>
Reply-To: sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host: clio.rice.edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> [CWS's] statement was not quite complete.  V2 Load times are [decreased]
> because memory allocated by sbrk() (and thus malloc()) is not zeroed.

This also includes the stack.  If you have lots of memory, the amount of
time to zero a few MBs is neglible, but on a small memory machine this
causes lots of paging.  It's reduction in paging on small to medium sized 
machines which has the most dramatic improvement on speed.

If an application relies on the stack being initially zero (or malloc'ed
memory being zero on the first access) there is a "bug workaround bit"
which allows memory zeroing (in addition to the 0xdeadbeef value DJ
mentioned in his message) in crt0.h.

Developers need the zeroing to find and fix bugs too - when I ported the
debuggers to V2 they would not run without the "zero memory" bit set
until the bug in symbol names was found and fixed.