Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!overload!dillon
From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:  free() in SAS C
Message-ID: <dillon.7247@overload.Berkeley.CA.US>
Date: 4 May 91 19:15:40 GMT
References: <1991May02.143148.22732@edb.tih.no> <MWM.91May3182036@raven.pa.dec.com>
Distribution: comp
Organization: Not an Organization
Lines: 39

In article <MWM.91May3182036@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes:
>In article <1991May03.225751.26999@medar.com> jseymour@medar.com (James Seymour) writes:
>   No.  There is no ANSI compatable (or even *remotely* portable) way to
>...
>
>It's pretty striaghtforward to write a couple of routines that map
>malloc/free to AllocMem/FreeMem, which might be acceptable in this
>case. It'll give you the behavior wanted for the large hunks, anyway.
>If you're doing lots of frees/allocs later on, you'll take a
>performance hit.
>
>	<mike

    Actually, AllocMem & FreeMem are *faster* than SAS/C's
    malloc & free.  The only loose is that your system is more
    susceptible to fragmentation.  The only other thing I notice
    sometimes is that on program exit it may take a little while
    longer (2 seconds instead of 1) to free the memory if the
    program has made a few thousand allocations.

    DICE currently uses AllocMem() & FreeMem() for malloc().  I will
    probably end up using Allocate & Deallocate in a private memory
    pool for small allocations, but leave larger ones to AllocMem()
    & FreeMem().

				    -Matt

>--
>Es brillig war. Die schlichte Toven			Mike Meyer
>Wirrten und wimmelten in Waben;				mwm@pa.dec.com
>Und aller-mumsige Burggoven				decwrl!mwm
>Die mohmem Rath' ausgraben.

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA