Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!sun-barr!newstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga.tech Subject: Memory usage Message-ID: <121373@sun.Eng.Sun.COM> Date: 14 Aug 89 19:40:08 GMT References:<1410023@hpcvca.CV.HP.COM> <7638@cbmvax.UUCP> Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 59 In article <7638@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > Well, if you use the C library routines malloc() and free(), there is >no _need_ to free everything, since the library implementation and exit() >code takes care of freeing malloc()ed memory. Doesn't mean I like the >practice: it places more reliance on the malloc to be unix-compatible, and >precludes replacing malloc (easily) with lower-level memory calls with less >overhead than malloc (such as AllocMem, or something like it). Doing something >like that saved me over 1K, by dumping malloc, and made my program run faster. Rewriting malloc to be faster is an old game, lots of people play. This whole bit about memory usage and calls are a religious argument but the two sides can be pretty clearly defined : The Package Argument : I use a memory management package that keeps track of what I allocate and free, when I exit the program I call the deallocate everything entry point and everything gets freed. I like this because I don't have to worry about what is and isn't freed. The System Call Argument : I use the system calls for allocating and freeing memory because I want to be absolutely sure I'm only using the memory I need, and don't like the overhead of memory management packages. I have to write some extra code in my exit routine to make sure I've taken care everything but the benefit is extra flexibility. Both are valid arguments, and they often depend on what you are trying to do. I tend to use a mixture because of the way in which the Amiga must have Chip ram for some things and my programs tend to build gadgetry and such on the fly. > Another reason I prefer a style where everything is freed is that it >makes the code more reusable: you can take a subroutine and use it, and not >have to worry about using immense mounts of virtual space that you are no >longer using. (Since you may use it repeatedly in a loop without exiting, >if it drops memory every time it can add up quickly.) This, on the other hand, is specious. If one writes a subroutine that has a memory leak then that is a bug in any system. If you are building data structures and returning them to your client that's one thing, but losing memory is just a bug. > As you might guess, I'm not a big fan of garbage collection. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. You're comment implies that memory management packages have to be large cumbersome beasts that lose memory and must be scavenged periodically to defragment them. This is demonstrably untrue, so you must mean something else. The true advantage to memory management packages over system calls is that one can port them, and then all of your code works, rather than having to go into the code and find all occurrances of AllocMem() or what have you. In the case of malloc/free it just happens to be a defacto standard package because it works that way on UNIX. That means that you might not even have to port it when you get to the destination, and that saves time and energy. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"