NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/mac/programm/21033

Text File | 1993-01-08 | 1.9 KB | 47 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!kip-28.taligent.com!user
From: [e-mail] (Keith Rollin)
Subject: Re: Why is new(p) so slow in THINK Pascal?
Message-ID: <[e-mail]>
Followup-To: comp.sys.mac.programmer
Sender: [e-mail] (More Bytes Than You Can Read)
Organization: Taligent
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Jan 1993 21:03:22 GMT
Lines: 34

In article <[e-mail]>, [e-mail] (Rich Siegel)
wrote:
>
> In article <[e-mail]> [e-mail] writes:
> >In order to compare some sorting procedures for linked lists (implemented
> >in THINK Pascal) I applied them to random lists of varying lengths.
> >It turns out that the procedure new(p), which allocates storage for
> >a dynamic variable pointed to by p, is extremely slow.  Does anyone
> >know why?  New-ing a thousand items takes a noticeable time, new-ing
> >10,000 items takes minutes (on my lowly SE/30).
>
> New() for pointer variables simply calls NewPtr. With that many small
> blocks, you're overloading the Memory Manager, which has to find space
> low in the heap each time you call New. Under the circumstances, you
> might want to think about an alternative storage strategy.
>
> Starting with an initial free list of pointer blocks is OK, but you're
> still hammering the Memory Manager - you might want to think about
> allocating a single large chunk and using pieces of it as you need them.

MPW Pascal, as well as malloc() in both THINK and MPW C, does this.
Chunking instead of calling NewPtr each time is a *big* win. I did a simple
test:

p = NewPtr(50) 10,000 times = 3917 ticks
h = NewHandle(50) 10,000 times = 238 ticks
p = malloc(50) 10,000 times = 26 ticks.

...on my lowly Quadra 900.   :-)

-----
Keith Rollin
Phantom Programmer
Taligent, Inc.