Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!wgate!lanzo
From: lanzo@wgate.UUCP (Mark Lanzo)
Newsgroups: comp.lang.c
Subject: Re: Why use -lmalloc
Message-ID: <179@atesysv.UUCP>
Date: 1 Apr 91 13:53:31 GMT
References: <2@bodedo.UUCP>
Reply-To: lanzo@atesysv.UUCP (Mark Lanzo)
Organization: Wandel & Goltermann Technologies, Inc.
Lines: 28

In a prior article jon@bodedo.ucm.org (Jon Boede) wrote:
    I've been puzzled about the existence of a second library for
    malloc on my system for some time (I have a SCO '386 box).  Other 
    than being tunable beyond my wildest dreams, what does using -lmalloc 
    buy me?  What does it cost me?  I would assume that there's a tradeoff 
    or there'd only be one library entry.

Well, I can't say anything about SCO '386 Unix, but I can tell you what
it buys you on HP-UX:

		** SPEED **

It is a whole lot faster.  We have a big X-windows application we are
working on.  We changed our makefiles to link with -lmalloc -- program
startup times in our case dropped by an order of magnitude. (say, from
5 minutes down to 30 seconds).  I saw the light :-)

Tradeoffs?  I can't think of any real problems.  Here's what our man 
pages have to say:

    This package usually uses more data space than malloc(3C).
    The code size is also bigger than malloc(3C).
    Note that unlike malloc(3C), this package does not preserve
    the contents of a block when it is freed, unless the M_KEEP
    option of mallopt is used.
    Undocumented features of malloc(3C) have not been duplicated.

Gee.  How awful.  It doesn't support the bad programming practices
that the original malloc would let you get away with :-).