Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!dlyons From: dlyons@Apple.COM (David A. Lyons) Newsgroups: comp.sys.apple Subject: Re: Error $0201 Message-ID: <38528@apple.Apple.COM> Date: 11 Feb 90 06:00:24 GMT References: <1990Feb9.205226.22194@spectre.ccsf.caltech.edu> <38506@apple.Apple.COM> <1990Feb10.005833.24732@spectre.ccsf.caltech.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 47 In article <1990Feb10.005833.24732@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >[...] >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. No solution is ideal in every respect. I have not given much thought to how a B-tree scheme would fit in with the GS memory manager, but it seems it would take -more- RAM per handle for the data structures. True, a data structure fancier than a doubly-linked list would let the memory manager find which handle owns a given address faster, but how much of the time does it spend doing that, anyway? The memory manager doesn't have to search through the handle chain to find a handle for any mem mgr calls that already -supply- the handle (it just does a simple validity check on the forward and backwards links). In the normal case of allocating a movable block of memory, the 5.0+ memory manager no longer scans through the handle list, either. >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 [...] You can't narrow it down to a single source of blame--I haven't examined all the code, but I believe the memory manager to be reasonably efficient. When you have a lot of overlapping windows, you get some complicated regions for QuickDraw II to keep track of. The Window Manager lives on top of QuickDraw and does still more region operations. Regions are stored in handles, but I suspect most of the time is spent manipulating the region data rather than actually doing memory manager operations on the handles. -- --David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.