What's really up with emacs

[Tim Bray]

In article <1558 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
 To paraphrase: GNU Emacs uses a simple-minded gap-based system for
 managing buffer memory, and ...
>Unfortunately as it is implemented in GNU emacs the "gap" method is a
>disgrace for performance because:

Many reasons given, quite plausible-sounding.
>What are the solutions?

Hold on.  What makes you think you know what the problem is?  Have you
instrumented it with the profiler and quantified the overhead of this
"problem"?  My own intuition is that GNUmacs spends much more time
CONSing and otherwise chugging through the innards of the Lisp
interpreter.  But I wouldn't bet $0.50 on my intuition unless I had a
good quantitative understanding of what's going on.

You propose putting in linked-list logic.  Let me point out that the gap 
system has the *immense* advantages of being simple, comprehensible, very 
compact, and proven robust.

You're going to be awfully disappointed when you spend weeks hacking a new
buffer manager in, and the size of the code grows substantially, and it's 
less reliable, and then it doesn't feel any faster.

Haul in soapbox, climb up: I see a lot of this particular error.  After
a few years in the field, we learn a lot of things about what makes
programs fast or slow, and we start to suffer from the delusion that we
can apply our intuition to performance issues in large systems.

How to make software fast:

 o Use good algorithms from the top down, and
 o Make everything simple as possible, and
 o After it works, instrument it and find out where it's spending its time.
   Then go back and use better algorithms in the slow parts.

Climbing off the soapbox and turning to another emacs issue, rlk at think.com 
(Robert Krawitz) says:

>2)  Emacs dies very quickly after its virtual size exceeds 16 Mbytes,
>due to the 24 bit pointers used (the top 8 bits are used as tag bits for
>the Lisp interpreter).  

Yes, and a lot of other problems too.  Any serious programming language
(Elisp is a serious programming language) with 24 bit numbers is in deep
trouble.  Fairly efficient solutions to this problem exist in other
lisp implementations, and one will have to be hacked into Gnumacs.

Finally, woods at robohack.UUCP (Greg A. Woods) writes:

>Your article has convinced me that GNU Emacs is indeed, in my case, a
>waste of disk space.  

That may be true, but nobody has presented any serious evidence to support
such a conclusion.

Cheers, Tim Bray, 
Open Text Systems, Waterloo, Ontario, Canada