Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.unix.questions
Subject: Re: sbrk(2) question
Message-ID: <4364@skye.ed.ac.uk>
Date: 26 Mar 91 13:50:57 GMT
References: <1991Mar8.180132.12025@Think.COM> <4296@skye.ed.ac.uk> <6582@auspex.auspex.com> <4312@skye.ed.ac.uk> <2045@necisa.ho.necisa.oz.au> <4319@skye.ed.ac.uk> <534@bria>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 26

In article <534@bria> uunet!bria!mike [whose articles arrive without
a From: line] writes:

>The stock mallocs are piggishly slow beasts.  Rephrase:

>``On the other hand, there's not usually a good reason to not just use
>malloc() unless you need reasonable performance.''

malloc() is unlikely to be slower than sbrk() unless *extremely* badly
implemented, since sbrk() is a system call.  For good performance, it
may be best to allocate a large block of space and allocate fragments
of it yourself, especially if you need fixed-size allocations.  If you
do this, then it won't make much difference (to speed) how you allocate
the large block.

Someone else remarked that it is difficult to be sure that you're
freeing the right memory when you use sbrk().  Actually it's easy -
just use sbrk(0) to check that the break is at the end of the memory
you're freeing.  If it isn't, someone else has allocated memory so you
can't free it.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin