[gclist] What wrong with the GC in xemacs

[Erik Naggum]

|   We all know that the GC in emacs is bad, but what is wrong with it?

that it makes its presence known.

I have run some tests at the U of Oslo with about 100 users who generally
agreed that Emacs had become faster in the latest Emacs pretest.  all I had
done was to remove the "Garbage collecting" message which people perceive
as slowing Emacs down and tell them that it had been sped up.  it is,
somehow, permissible for a program to take a lot of time doing any other
task than administrative duties like garbage collection.

|   Could it be fixed, as a lot of peoples image of GC is emacs?  The speed
|   and size of emacs also puts me of "lisp" based system.  Is the GC the
|   problem, or is it that emacs is based on "lisp".

Emacs' is a particularly slow implementation of Lisp, with several painful
limitations on speeding it up.  for starters, the arguments to functions
are bound dynamically, making function calls inordinately expensive.

however, there is so much of Emacs that runs in highly optimized C code
that I'm not sure you can pinpoint your criticism on Lisp or just a
perception of slowness because it does a lot more than it seems to do.
Emacs is much faster than other programs that do as much, only they talk
about what they do so the user is aware of it, and don't talk about the
things the users don't want to know about (like GC).  users seem to be
soothed by such noise message, but only if the machine is doing things on
their behalf that they have asked for or can understand is useful.

the code to make the garbage collection message go away is rather simple.
I'm trying to make it part of Emacs (under control over a variable).

I am not very well versed in GC.  do any of you know the Emacs GC well
enough to say something about how hard it would be to replace it with, say,
a generational collector?

#<Erik>