Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!uunet!zephyr.ens.tek.com!tektronix!percy!m2xenix!quagga!proxima!undeed!ucthpx!uctcs.uucp!gram From: gram@uctcs.uucp (Graham Wheeler) Newsgroups: comp.os.msdos.programmer Subject: Does TC's farrealloc have a bug? (summary) Message-ID: <1991Jun24.075451.20728@ucthpx.uct.ac.za> Date: 24 Jun 91 07:54:51 GMT Sender: news@ucthpx.uct.ac.za (UCT News Admin.) Reply-To: gram@uctcs.uucp (Graham Wheeler) Organization: Dept. of Computer Science, University of Cape Town Lines: 53 Thanks to all those who sent replies. The following reply is the most explicit. From: proxima!quagga!m2xenix!uunet!dartvax!eleazar.dartmouth.edu!crystal@Daisy.EE.UND.AC.ZA Organization: Dartmouth College, Hanover, NH In article <1991Jun19.083945.8921@ucthpx.uct.ac.za> you write: >I have an application in which I am allocating a number of variable sized >records, of average size about 6 bytes. Whenever the size changes, I use >farrealloc. I have over 300kb available at the time I start allocating these >nodes. I also keep track of the number of allocated bytes. My problem is that >I get a memory allocation failure at about 120kb of allocated memory. This >must mean one of two things: > >i) either there is a bug in TC (actually TC++ v1.0) so that when realloc > fails to resize a block and allocates a new one it doesn't free the > old one; or >ii) the allocated blocks are being held on a linked list with an overhead of > (I would guess) 12 bytes per block (two far pointers and one long size). > This would mean that my nodes are actually using up 3 times more memory > than I am actually using for record storage. > >Personally, I think it is better to have the free blocks on a linked list as >you get the maximum use from your memory that way. I don't know how TC does >it. > >Does anyone know which of these two theories is correct? Or is there a >different explanation? > When you use farmalloc/farrealloc, each memory request is separately allocated from DOS, with a granulation of 16 bytes (1 paragraph), and an overhead of another 16 bytes per request. The granularity of 16 bytes is so that only 16-bit segment address are needed to track the memory blocks. If you have dos 4+, try doing a system("mem /debug") from your program after allocating a few of these, and you will see of the separate blocks listed. Richard Brittain richard@einstein.dartmouth.edu ========================================================================== Bearing in mind that my allocations are on average six bytes, I would be using 32 bytes for each node, ie over 80% of memory will be wasted. A suggestion I got to get around this was to use the large memory model with a plain old malloc instead of farmalloc. I haven't tried this yet, but it may help. Otherwise I think I will just allocate one massive memory block and do my own allocation from that, so that I have none of this excess overhead. Thanks again! Graham Wheeler | "That which is weak conquers the strong, Data Network Architectures Lab | that which is soft conquers the hard. Dept. of Computer Science | All men know this; none practise it" University of Cape Town | Lao Tzu - Tao Te Ching Ch.78