From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Malloc and realloc problems Date: 18 Sep 2000 13:45:52 GMT Organization: Aachen University of Technology (RWTH) Lines: 38 Message-ID: <8q56ag$mv6$1@nets3.rz.RWTH-Aachen.DE> References: <969276437 DOT 311068 AT osiris DOT esoterica DOT pt> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 969284752 23526 137.226.32.75 (18 Sep 2000 13:45:52 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 18 Sep 2000 13:45:52 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hiper M.A.R. wrote: > Incoerent results are given deppending on how memory is malloc or > realloc: > a)Using a straight foward malloc > b)Trying to malloc in 1MB step > c)Trying to realloc in 1 to 10 MB steps. They're not really incoherent. The results are different, for the three modes, but that's not an incoherence, because is no guarantee whatsoever that they should be equal, to begin with. What you observe is that heap fragmentation can cause some fraction of available memory to becomme effectively unreachable to a program, and the size of the fraction will depend on the allocation strategy. > a) 124 125 I.e. you have about 124 Megs of RAM available, in principle. > b) 95 96 Allocation in chunks of 1 Megabyte wastes part of it, because chunk sizes will be rounded upwards, and some book-keeping overhead is also needed for malloc() to be able to work. > c) 1 35 36 > 2 42 44 [...] > 10 60 70 Realloc()ing 'upwards' is a bad stragety, and it gets worse the smaller the steps are. That's what this tells you. The reason behind this is that the free()d blocks from the earlier, small realloc() calls are not available for re-use as part of larger blocks, later on. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.