Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!spdcc!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.sys.sgi
Subject: Re: The memory eater strikes back (2nd attempt to get attention)
Message-ID: <1989Oct23.191407.13894@world.std.com>
Date: 23 Oct 89 19:14:07 GMT
References: <8910210901.aa24434@SMOKE.BRL.MIL> <89Oct21.211825edt.3287@neat.cs.toronto.edu>
Reply-To: madd@world.UUCP (jim frost)
Organization: Software Tool & Die
Lines: 26

About SGI's and memory leakage:

Something to remember is that the SGI graphical object library has
memory leaks.  This is a random fact that I ran into which I though
some people might be interested in.

In article <89Oct21.211825edt.3287@neat.cs.toronto.edu> moraes@CS.TORONTO.EDU (Mark Moraes) writes:
|Stay with the libc malloc unless profiling your application indicates
|that malloc is a bottleneck. At that point, consider custom allocation
|strategies for the most frequent uses of malloc. (like preallocating
|and managing memory pools of frequently used objects [...] )

The libc malloc slows considerably when dealing with many small object
allocations and deallocations (typically a few hundred thousand if I
remember right) where the BSD malloc degrades "reasonably"; pooled
allocations will improve performance dramatically if you are doing
this type of allocation on the SGI.

The libmalloc malloc, even if broken, is good to run some tests with
because it smashes the malloc'ed area; we found many bugs because of
this behavior (and even more when running on a machine which
disallowed null pointer dereferencing :-).

jim frost
software tool & die
madd@std.com