A tale of two C's.

[Mark Biggar]

In article <193 at chem.ucsd.EDU> tps at chem.ucsd.edu (Tom Stockfisch) writes:
>In article <474 at bnlux0.bnl.gov> drs at bnlux0.UUCP (David R. Stampf) writes:
>>>In article <154 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>>>>When portability is not an issue, a programmer should be free to use
>>>>his or her own implementation of a standard library function.
>>I have frequently found the need to chuck some of the standard library
>>routines in favour of locally written routines...
>>(in one example I didn't need the full generality that malloc
>>gave me, since I was always allocating fixed length blocks, so I wrote my own
>>that took advantage of the machine that I was running on (Mac)...
>Why would you want to call a function "malloc()" if it does not do the
>same thing that the malloc(3) man page says malloc() does?
>
>I would find it *very* confusing to read code in which malloc() (or any
>other standard library function) did something besides/instead of what
>it is supposed to.

Actually malloc is a case where rolling your own can provide emormous
speed up in your program.  Do you realize just how much overhead is added
to malloc just so you can free things.  I wrote a large (20000 lines)
program that used malloc everywhere.  The longer it ran the slower it got.
On profiling it I discovered that the program was spending 47% of its time
in malloc!  The program never freed anything, so I replaced malloc with a
much simpler one that just gave me some memory and didn't do any of the
screwy thing that the regular malloc does (like chase down a link list of
every block ever allocated to see if you might just have freed a block big
enough to honor the the current request).  This gave me a 40%+ speedup in
the program and the program stopped getting slower.  By putting the simple
replacement malloc in its own file, I made the program just as protable as
befor because you didn't have to use my malloc. (Altough mine would work
correctly on both bsd and SV type unix systems.)

Mark Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,akgua,sdcsvax}!sdcrdcf!markb
markb at rdcf.sm.unisys.com