Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw From: toddpw@tybalt.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple Subject: Re: Error $0201 Message-ID: <1990Feb10.005833.24732@spectre.ccsf.caltech.edu> Date: 10 Feb 90 00:58:33 GMT References: <1990Feb9.205226.22194@spectre.ccsf.caltech.edu> <38506@apple.Apple.COM> Sender: news@spectre.ccsf.caltech.edu Organization: California Institute of Technology Lines: 24 dlyons@Apple.COM (David A. Lyons) writes: >'scuse me? I'd like a chance to defend the Memory Manager, but you haven't >said what's wrong with it. I believe it to be a very nice and usable >design; not all programs use the memory manager in an intelligent way, >unfortunately. ok, you've got a point. While I can't claim to be on firm ground, I highly question the use of a linked list to keep track of memory blocks. A B-tree inherently sorted by starting address would IMHO be much easier to search and compact. I haven't written memory manager code of my own so I won't presume to know more than the author of the memory manager. But when you get lots of windows in finder, things get r-e-a-l s-l-o-w, and I have a hard time believing the memory manager is entirely innocent. I know that many toolsets allocate and deallcoate memory during their normal operation, and knowing that the allocate, deallocate, and purge code is extremely efficient would make me feel a lot better, knowing that the applications are at fault. Todd Whitesel toddpw @ tybalt.caltech.edu