jnh@ecemwl.ncsu.edu (Joseph N. Hall) (08/30/89)
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 could imagine a compromise solution, in this case, where I could allocate array storage for most objects (lines, rects, etc.) since they would all have a similar structure (bounding rect, pen type/style, ink, mode, etc.), and then tack on relocatable blocks for the "special" objects (bitmaps, text, etc.) that required additional information. But still ... I haven't seen a good discussion of the limits of the Memory Manager and I'm curious to know what, in fact, its practical limits are. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
lim@iris.ucdavis.edu (Lloyd Lim) (08/31/89)
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