Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!SCT60A.SUNYCT.EDU!sweetmr
From: sweetmr@SCT60A.SUNYCT.EDU (michael sweet)
Newsgroups: comp.sys.sgi
Subject: Re:  realloc reactions ??
Message-ID: <22347.on.Fri,.15.Feb.91.07:55:05.EST.@sct60a.sunyct.edu>
Date: 15 Feb 91 12:55:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

Actually, the way realloc() does its realloc'ing is implementation dependent
(oh, boy!)  *Most* realloc()'s try to expand the existing block first, and
only malloc() a new block if necessary.  This *will* create holes if you do
a lot of small realloc()'s; memory is generally grabbed in chunks which
are either a minimum size, or the size of the requested amount (whichever
is larger.)  As the amount you realloc() grows larger, you will create
(concievably) large wholes in the heap (if memory is not contiguous), and
causing much swap-space thrashing! :)  (voice of experience...)

The easy fix for this is to allocate memory in multiples of a minimum size,
reducing the number of realloc()'s you have to do; you'll also need a variable
(or structure field) which keeps track of the last amount allocated...

Or of course you can use the K&R malloc()/free() functions and add your own
realloc() which rounds request sizes to some minimum size multiple...

 -Mike Sweet

------------------------------------------------------------------------------
"The only        TASC                      (315) 724-1100 (voice)
 truth is that   555 French Road           (315) 724-2031 (fax)
 there are no    New Hartford, NY  13413   Internet: sweetmr@sct60a.sunyct.edu
 truths, only beliefs."                    Delphi:   DODGECOLT
------------------------------------------------------------------------------