home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / alt / lucidem / help / 666 < prev    next >
Encoding:
Text File  |  1992-11-09  |  1.5 KB  |  34 lines
  1. x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Mon, 9 Nov 1992 16:48:56 EST
  2. Message-ID: <9211091815.AA11299@thymus.synaptics>
  3. Subject: Re: GC idea
  4. Reply-To: daveg@synaptics.com
  5. Date: Mon, 09 Nov 1992 10:15:24 -0800
  6. From: daveg@thymus.synaptics.com (Dave Gillespie)
  7. Newsgroups: alt.lucid-emacs.help
  8. Path: sparky!uunet!wendy-fate.uu.net!help-lucid-emacs
  9. Sender: help-lucid-emacs-request@lucid.com
  10. Lines: 22
  11.  
  12. Dirk Grunwald writes:
  13. > Actually, mayhaps it's time for a general discussion of the current GC
  14. > scheme. Switching to a generational scheme would reduce the relatively
  15. > large interactive ``hit'' you take in Emacs.
  16.  
  17. It would be really great to have something like this.  I find that
  18. after a while my Emacs process gets to be quite large, but mostly
  19. swapped out.  As I understand it a generational GC would let most of
  20. that stuff stay swapped out, whereas the current GC has to bring it
  21. back into memory on a regular basis.
  22.  
  23. I doubt you'd need something as complicated as a generational GC
  24. just to fix the interactive response time problem, though.  Even
  25. the GC-during-idle-time scheme would fix 90% of the problem.
  26. Another idea I had was to arrange the current GC algorithm to be
  27. able to abort itself quickly if there is any user input.  Right
  28. now the GC algorithm clears marks as it is sweeping; you'd need
  29. to change it to do an explicit unmarking phase at the beginning
  30. of GC, which would slow it down a bit.  But since GC would be
  31. interruptable, it wouldn't matter nearly so much how long it took.
  32.  
  33.                                 -- Dave
  34.