Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!mips!apple!uokmax!servalan!epmooch!ben From: ben@epmooch.UUCP (Rev. Ben A. Mesander) Newsgroups: comp.sys.amiga.programmer Subject: Re: Memory fragging Message-ID: Date: 29 May 91 12:43:20 GMT Article-I.D.: epmooch.ben.3240 References: <1991May21.195251.16477@zorch.SF-Bay.ORG> <21795@cbmvax.commodore.com> <2885@public.BTR.COM> <1991May28.162254.31102@kuhub.cc.ukans.edu> Organization: Elvis Presley Museum Of Obsolete Computing Hardware Lines: 30 In article <1991May28.162254.31102@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: [...] >I'm playing with some Alloc/Free replacements for exec.library that do >similar things as well as "best-fit" allocation instead of "first-fit". It would be nice to have a memory allocation debugging tool for those of us who are not lucky enough to have an MMU. One thing though; I thought common wisdom was that best fit allocation often produces more fragmentation than first fit allocation. Am I out of date? >The problem here is it really helps to have a task private tracking pool but >doing this on exec.library is tough (almost nobody OpenLibrary()s >exec.library). Well, maybe your program would provide an incentive :-) >One bit of expirimentation determined that rounding up all allocations >to the nearest power of 2 (ie 1K 2K 4K) with a limit on max >granualarity (32K works well since it will hold the average bitplane >which is one of the largest common come/go allocations) in conjunction >with best-fit allocations seems to almost completely eliminate fragging. What do you do with very small allocations? -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |