home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / 19414 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.2 KB  |  43 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!orca!orca!pmartz
  3. From: pmartz@dsd.es.com (Paul Martz)
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov20.224644.10664@dsd.es.com>
  6. Sender: usenet@dsd.es.com
  7. Nntp-Posting-Host: bambam-gw
  8. Reply-To: pmartz@dsd.es.com (Paul Martz)
  9. Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT
  10. References: <RJC.92Nov13144522@daiches.cogsci.ed.ac.uk> <1992Nov16.162457.2923@osf.org> <1ebs7rINNp9k@armory.centerline.com> <1992Nov19.040434.12181@osf.org> <1ejeh8INN1jq@armory.centerline.com>
  11. Date: Fri, 20 Nov 92 22:46:44 GMT
  12. Lines: 29
  13.  
  14. In article <1ejeh8INN1jq@armory.centerline.com>, jimf@centerline.com (Jim Frost) writes:
  15. > dbrooks@osf.org (David Brooks) writes:
  16. > Look at it this way -- if you do all allocations in a power of two
  17. > then to have a list for every possible different sized allocation you
  18. > need only thirty-two lists (actually 28 or 29 depending on the minimum
  19. > allocation size, or even fewer if you consider that you can't really
  20. > allocate a 4 gig area).  That's real convenient -- you can basically
  21. > find an empty space (if there is one) immediately, making your
  22. > allocator REALLY fast.  It's my assumption that that's what the GNU
  23. > malloc does, although I've never looked it the code.
  24. > 
  25. > The downside is that it's wasteful for allocations that don't fit
  26. > well.  An 65-byte allocation will return 128 bytes.  No big deal, at
  27. > least as long as you're not doing a lot of those allocations.  As the
  28. > sizes get larger, however, it becomes a really big deal -- a 1.1
  29. > megabyte allocation will return 2 megabytes, for instance.  Once you
  30. > have a few of those you're starting to really waste memory.
  31.  
  32. Everything's a trade-off. Why get a 2meg chunk for a 1.1meg request?
  33. Go get 1.1meg instead, and stick it in a list for chunks sized between
  34. 1 and 2 megs. Then finding a free chunk the correct size becomes a
  35. matter of searching through the list of similarly sized chunks to find
  36. one big enough to fulfill the request. Slightly less time efficient
  37. than the algorithm you outline above, but it licks your memory
  38. efficiency issue. Maybe not quite as good at handling fragmentation.
  39. -- 
  40.  
  41.    -paul    pmartz@dsd.es.com
  42.         Evans & Sutherland
  43.