[gclist] What wrong with the GC in xemacs

[Kaelin Colclasure]

Daniel Barlow wrote:
> 
> >|   reading your mail and the whole 200 message folder should be sitting
> >|   quiescent in swap, it's still getting paged in.
> >
> >it isn't unless you select that buffer.
> 
> *Something* is.  Emacs is noticeably slower when that vm buffer is
> there, unused, than it is when it isn't.  If it's not the buffer
> itself, maybe there is other data that vm is using to do its job, that
> also takes up significant space?

Rmail of course has to keep some data structures around to avoid having
to continuously re-parse through the whole buffer full of messages.
Naturally the data structures are Lisp objects and therefore are touched
by the collector.

[...]
> Which is exactly what this thread was about, no?  I don't recall the
> exact words which started it, but the discussion was certainly along
> the lines of `people's impressions of gc are adverselg influenced by
> emacs, so let's look at it and see what's wrong with it'.
> 
> The particular post I responded to suggested that not much was wrong
> with emacs gc; I responded to assert that something definitely _is_.

Every piece of software in existance represents a collection of design
trade-offs and assumptions made to achieve what the designers considered
important.  For Emacs, the single most important feature was extensibility
and considered in that light Emacs has to be one of the most wildly
successful software products ever implemented.  However, THERE'S NO SUCH
THING AS A FREE LUNCH.  The price of all that extensibility is largely
paid in memory footprint.

If you can't afford it-- well, then you can't have it.  Use vi or some
other editor that was implemented with a different set of design criteria.
If you *must* have Emacs, then you *must* have enough memory to use it
effectively.

Why of all engineering disciplines is software so universally perceived
as not being subject to any constraints of reality?  If a structural
engineer says it'll take a hunderd tons of steel to build a bridge to
span a river, she's usually taken at her word as a professional and a
hundred tons of steel is procured.  If a software engineer says a program
needs thirty megabytes of RAM, you can count on someone trying to run it
in four or eight.  If it fails outright that's well and good-- but if
through the herculean efforts of the VM system it limps and struggles
along and completes its tasks anyway then frequently the engineer is 
criticised for having produced a poor design or implementation.

Perhaps this is why we software engineers as a body feel so much pressure
to use C and similar "highly efficient" but error-prone tools to build all
of our products-- even when a small memory footprint and minimal machine 
instruction counts aren't "real" design criteria.  It's sort of like our
structural engineer re-designing her bridge to use thirty tons of
tungston instead of a hundred tons of steel.  Sure, it uses less resources
if your sole measure is mass-- but the cost is enormously higher because
tungston is a hell of a lot more expensive than steel.

And lest this message be percieved as completely off-topic :-), I'll add
that garbage collection is also a technology that has some associated
costs as does manual storage management.  While specific details are
subject to debate, I think we can all agree that the costs (and benefits)
are *different* and that sometimes those differences force an implementor
to choose one technique over the other in order to meet more important
design criteria (tungston does have its uses, after all).

-- 
// Kaelin Colclasure -----------------------------------------------------
// Mailto:Kaelin@Bridge.COM       USMail: Bridge Information Systems, Inc.
// Voice: (314)567-8463                   717 Office Parkway
//   Fax: (314)432-5391                   St. Louis, MO 63141