home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / programm / 5666 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  1.4 KB
  1. Path: sparky!uunet!munnari.oz.au!manuel.anu.edu.au!coombs!avalon
  2. From: avalon@coombs.anu.edu.au (Darren Reed)
  3. Newsgroups: comp.unix.programmer
  4. Subject: Re: allocating memory pages
  5. Date: 12 Dec 92 16:13:36 GMT
  6. Organization: Australian National University
  7. Lines: 24
  8. Message-ID: <avalon.724176816@coombs>
  9. References: <1ga7o0INNdts@sequoia.ccsd.uts.EDU.AU>
  10. NNTP-Posting-Host: 150.203.76.2
  11.  
  12. M.Gream@uts.EDU.AU (Matthew Gream) writes:
  13.  
  14.  
  15. >Im writing an application for SunOS that uses a large pool of
  16. >buffers (128-256, each 4k) initiallised at the beginning of
  17. >execution and filled/pushed/pulled/moved around during execution,
  18. >I was wonder whether there would be any performance increase
  19. >on aligning each buffer to a page (and indeed they would constitute
  20. >one page each), if so, how is it done?
  21.  
  22. Try valloc(2).
  23. How good this is will depend on whether Sun's libc will want to
  24. add to that for its own malloc support (tree structure).
  25. If you dont have to worry about portability, use sbrk(2) and write
  26. your own memory allocation/management routines.
  27.  
  28. Whether you get any performance improvement will depend on how often
  29. buffers are going to be used, etc.  If you allocate a lot at one stage
  30. and dont use them again for quite some time you could be lucky and
  31. have their pages swapped out without affecting anything else.  Again,
  32. this will depend on what Sun's libc does when it uses a valloc or malloc
  33. call...just get Sun's source and have a look......
  34.  
  35. darren
  36.