home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / x / 19347 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.3 KB  |  48 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!llyene!thyme!kaleb
  3. From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
  4. Subject: Re: FLAME, FLAME ON X!!!
  5. Message-ID: <1992Nov19.180858.642@thyme.jpl.nasa.gov>
  6. Organization: Jet Propulsion Laboratory, Pasadena, CA
  7. References: <1992Nov16.162457.2923@osf.org> <1ebs7rINNp9k@armory.centerline.com> <1992Nov19.040434.12181@osf.org>
  8. Date: Thu, 19 Nov 92 18:08:58 GMT
  9. Lines: 37
  10.  
  11. In article <1992Nov19.040434.12181@osf.org> dbrooks@osf.org (David Brooks) writes:
  12. >jimf@centerline.com (Jim Frost) writes:
  13. >
  14. >>Unfortunately power-of-two allocation is remarkably wasteful of
  15. >>virtual memory (which means wasteful of real live swap space on many
  16. >>systems).
  17. >
  18. >Then why have I heard people recommend using gnu malloc with X, people who
  19. >I thought would be in the know?  The only gnu mallocs I've seen use
  20. >exclusively power-of-two allocation, and don't attempt to split a larger
  21. >block or merge blocks on free.  There's even a comment:
  22. >
  23.  
  24. But which GNU malloc?  The one in emacs and gcc or their "beta" version?  
  25. They are different!  The one in emacs is very similar to the berkeley 
  26. malloc, which is blazingly fast, but very poor at managing fragmentation 
  27. of the malloc "arena" a.k.a. the heap.  Ironically, fast but inefficient
  28. is probably okay for gcc, but exactly the opposite of what you want for
  29. emacs, an X server, or any other long running malloc-intensive application.
  30.  
  31. Several vendors have very good malloc packages, and others don't.  Some
  32. vendors provide alternative malloc packages that emphasize size over speed;
  33. usually you link with -lmalloc to get this one, if it's available.
  34.  
  35. Early in X11R4 I ran a series of benchmarks on the MIT Sample X Server using
  36. some of the various mallocs publically available, two proprietary mallocs 
  37. (people sent me their compiled binaries), plus the standard malloc that 
  38. comes with SunOS C runtime library.  The tests were not really scientific, 
  39. so the results are by no means conclusive, but I would offer that while 
  40. demonstrably slower, SunOS, GNU beta, and AT&T SVR4 mallocs appear to make 
  41. more efficient use of the heap than the emacs and berkeley mallocs.
  42.  
  43. -- 
  44.  
  45. Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov
  46.  
  47. Not authorized, in any way, shape, or form, to speak for anyone.
  48.