Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!Shasta!gus
From: gus@Shasta.UUCP
Newsgroups: net.micro.mac
Subject: Re: Macintosh C comparisons?
Message-ID: <464@Shasta.ARPA>
Date: Mon, 28-Apr-86 21:18:03 EDT
Article-I.D.: Shasta.464
Posted: Mon Apr 28 21:18:03 1986
Date-Received: Sat, 3-May-86 21:09:03 EDT
References: <2392@decwrl.DEC.COM> <336@tolerant.UUCP> <1454@garfield.columbia.edu>
Organization: Stanford University
Lines: 23

> does the fact that Lightspeed C programs do not work well under heap
> scramble imply that their memory management routines are buggy?

Not exactly buggy, but slow. I am doing a benchmark on various C compilers.
Although the final results aren't in yet, one thing is clear. Calls to malloc
should NOT translate directly into Mac memory manager calls. Aztec,
Lightspeed, and Consulair do this while Megamax and Lisa Workshop C have
a two-stage malloc. As a result, 5,000 element treesort takes about 300
seconds on the former set and 5 seconds on the latter. Lightspeed has 
two sets of storage allocation routines. The first set (malloc, free) 
take linear time to execute in the number of consecutive calls, while
the second set (getmem, freemem) exhibit the constant time performance which
allows treesort to work at the expected n log n speed.

Now some might say that you really shouldn't be using standard C routines 
for Mac code. The storage allocation primitives, however, are arguably
an exception which should not be overlooked. These routines SHOULD be
optimized to be as fast as possible and still use the Mac heap architecture.
The best way to do this is to provide a two-level memory allocation heirarchy
which allocates LARGE blocks from the memory manager, and splits these up
into small blocks as requested by the user.

							Gus Fernandez