Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!emory!hubcap!grimlok
From: grimlok@hubcap.clemson.edu (Mike Percy)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Does TC's farrealloc have a bug? (summary)
Message-ID: <1991Jun26.143101.16662@hubcap.clemson.edu>
Date: 26 Jun 91 14:31:01 GMT
References: <1991Jun24.075451.20728@ucthpx.uct.ac.za>
Organization: Clemson University
Lines: 65

gram@uctcs.uucp (Graham Wheeler) writes:

>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) 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

Not the case here...but

>>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.

It's actually one far pointer (to previous block in list), and a long
for size.  The second far pointer (to the next block) is derived from
the current block address + size, since the next block is immediately
after the current block in memory.  The granularity is 16-bytes; this is
to simplify tehg overhead computations.  If you are farmalloc()ing lots
of small items, you can be hurt by this.  If you need to allocate lots
of small, smae-size objects, try managing the list yourself.  Smae-size
objects require less work/overhead than arbitrary sized objects.

>>
>>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.
 
For a description see my letter to the editor in Nov. 1990 C Users
Journal.  I might be able to dig it up and post it here if anyone's
interested.

>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.

No, since the overhead is only 8 bytes, a siz byte request is satisfied
by a 16-byte block.

>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.
  
Won't help -- malloc() in large data memory models (compact, large,
huge) is simply coerced into a call to farmalloc().  These memory models
do not maintain near and far heaps.  It might help to use samll data
memory models and malloc (overhead is 4 bytes, granularity is 8 bytes)
but if your data size is 6 bytes (4+6 = 10, need two block == 16 bytes
-- same as before!).

>Thanks again!
 
Sure thing.  I'll send you the article or post it sometime in the very
near future.

"I don't know about your brain, but mine is really...bossy."
Mike Percy                    grimlok@hubcap.clemson.edu
ISD, Clemson University       mspercy@clemson.BITNET
(803)656-3780                 mspercy@clemson.clemson.edu