Path: utzoo!attcan!uunet!midway!linac!att!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga Subject: Re: The Art Department and Memory Message-ID: Date: 10 Nov 90 21:35:33 GMT References: <1990Oct25.193715.8382@hayes.ims.alaska.edu> <1990Oct25.224025.7029@ux1.cso.uiuc.edu> <1611@madnix.UUCP> <1990Nov5.053442.4010@uokmax.ecn.uoknor.edu> <35817@cup.portal.com> Organization: Drew University/NJIN Lines: 52 In article <35817@cup.portal.com> Classic_-_Concepts@cup.portal.com writes: > "By its very nature, TAD requires a lot of memory. In fact > TAD will utilize as much *contiguous* (emphasis mine) memory > as you have on your machine. While it can run in as little At one time I considered pre-allocating all the memory that I *might* need right at program start. I figured it would avoid the need to check every my_alloc_mem() for failure. It would also mean that I could deallocate everything easier. The former would completely avoid the "out-of-memory crashes" that people complain about. It turned down the idea because I didn't want to waste the memory; other programs could use that memory when I'm not using it. The phrase I invented to describe the technique was that the program "made it's own sandbox so that it could ignore the others". I thought it that if I wrote a program that did this people would accuse the technique of being a holdover from the C-64 mentality. "If I can't have the whole machine, I'll just make my own mini-machine and stay within it." ASDG's technique has similar qualities but is one step closer to "making your own sandbox" because it's a contiguous block (or "box"?). Now I understand how ASDG makes their software so reliable. :-) This all confuses me because ASDG is the one company that I've never seen have a C-64 mentality. Maybe I'm off the wall and this is an accepted technique that everyone uses. What I do now is try to reduce X, where X is the number of calls to Alloc(). ASDG has taken this to an extreme. I can understand this for a program that will be doing many, many Alloc()s and Dealloc()s, but with TAD there are few times when Alloc()s are done. (This is based on the assumptions since I have only watched TAD being used, I've never seen the source code or monitored it's memory usage as the program is run). Specifically, I would assume that Alloc()s and Dealloc()s would only happen when modes are switched, new pics are loaded, or new pics are being generated based on other pic(s). That's a pretty low X. I could understand pre-allocating everything to do with ARexx handling and some UI work, but this is extreme. This isn't a flame. I'm just wondering if my theory is correct, and how others feel about this programming technique. I understand that Art Department Pro will have some user-settable memory usage control. I'm not against this technique, I'm just wondering if it's a one that should be taken to such an extreme. -Tom -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"