Re: t and nil in pure memory?

[Stephen J. Turnbull]

Executive summary:

YMMV but my take is that the XEmacs experiment "failed" due to social
reasons, not technical ones.

Ken Raeburn writes:

 > I'm looking now... though most of it seems to be "maybe we should  
 > consider doing this" type traffic.  There's a report that a "very  
 > limited experiment" with XEmacs found it to be slower, but not much  
 > analysis of why.

That measurement was based on profiling and guessing at the actual
size of the slowdown.  The correct interpretation of "slowdown" is
that it was due to the overhead imposed by the precise collector,
which had not been removed, merely disabled.  I believe the reasons
that the experiment was not extended were

1.  It wasn't believed to be enough *faster* to justify the effort,
    believed to be substantial, to remove the existing collector's
    overhead code, and to analyze places where more precise collection
    would be apropriate (at that time the version of Boehm GC in use
    wasn't very helpful in that respect IIRC).
2.  The VM footprint of a long-running process increased by about 20%
    and of the RSS by about 40%, meaning more effort to tune Boehm GC;
    those were pretty significant numbers back then when XEmacs
    expanded to "Ten times Eight MB And Constantly Swapping".
3.  Mike Sperber had a student who wanted to work on a pluggable GC
    concept which would allow experimenting with different GC
    systems (which evolved into today's --kkcc and --newgc options to
    configure in XEmacs).

If you need more details I could go back and look it up, but I really
don't think there's any useful information to be had.  The experiment
was no joke, but it was very limited, just as you wrote.