Path: utzoo!utgpu!watmath!att!ucbvax!ucdavis!iris!lim From: lim@iris.ucdavis.edu (Lloyd Lim) Newsgroups: comp.sys.mac.programmer Subject: Re: Proliferating Objects? How Many Is Reasonable? Message-ID: <5225@ucdavis.ucdavis.edu> Date: 30 Aug 89 19:39:11 GMT References: <3804@ncsuvx.ncsu.edu> Sender: uucp@ucdavis.ucdavis.edu Reply-To: lim@iris.ucdavis.edu (Lloyd Lim) Organization: U.C. Davis - Department of Electrical Engineering and Computer Science Lines: 29 In article <3804@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >In the introduction to the object-oriented extensions in the THINK C 4.0 >manual, there is a discussion of efficiency and use constraints. It's >pretty vague. > >If I were to implement something like an object-oriented drawing package, >or some other application that required that hundreds or thousands of >objects (potentially) exist in memory at once, would I be better off >bypassing the Memory Manager, doing my own garbage collection, etc.? >(Let's pretend they were all allocated as relocatable blocks.) I helped work on a CAD program that kept all of its objects (drawing objects) in relocatable blocks connected in doubly-linked lists. We never noticed any problems with the Memory Manager. I imagine that there is some overhead with the Memory Manager but even with very large files we didn't seem to have any problems. If there was a performance problem, we could always track down a part of our code that could be improved (and this isn't a comment on our code which was fairly clean). One interesting thing I learned there is that it's usually best to leave everything unlocked and let the Memory Manager move things around as needed. We very rarely locked things down in the middle of calculations. Most math calculations don't move memory and a handle dereference is cheap when the Mac might need some memory for some update region or whatever. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616