Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!sizzlean!lippin From: lippin@sizzlean.berkeley.edu (The Apathist) Newsgroups: comp.sys.mac.programmer Subject: Re: ARRGH (Strings and things) Message-ID: <1989Nov1.204513.1183@agate.berkeley.edu> Date: 1 Nov 89 20:45:13 GMT References: <16004@netnews.upenn.edu> <8835@hoptoad.uucp> <16420@dartvax.Dartmouth.EDU> <8852@hoptoad.uucp> Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: lippin@math.berkeley.edu Organization: Authorized Service, Incorporated Lines: 37 Recently tim@hoptoad.UUCP (Tim Maroney) wrote: >I get a different moral out of this -- don't unload segments. I use so >many function pointers in my code that it's impossible anyway, so I >don't have this problem. As far as I'm concerned, UnloadSeg was >relevant only to the Mac 128K.... Are you crazy? Unloading segments is one of the handiest ways available to save memory. If you don't swap your code to disk using UnloadSeg, you'll have to swap your data that much sooner, and data swapping is much more expensive (as you have to write it out before purging it). Perhaps you swap nothing? Then you're forcing the user to make your MultiFinder partition much larger that it should need to be. Think of all the features of your program that are only used occasionally -- that could all be saved for data space. (BTW, using function pointers is no excuse; a true Jedi's development system uses pointers to jump table entries.) >Another moral -- if you *do* unload segments, then link your glue >routines into the main code segment, so they will never be unloaded. Now that's a good idea. Also, your low-on-memory code (you do have some, don't you?) shouldn't be swapped out, unless you're really careful about it. >These are not my opinions, those of my ex-employers, my old schools, my >relatives, my friends, or really any rational person whatsoever. Wish that were true! --Tom Lippincott lippin@math.berkeley.edu "Foo, you are nothing but a charlatan!" --Adventure