delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/12/02/08:51:24

Date: Thu, 2 Dec 1999 13:28:21 +0100
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id: <199912021228.NAA12108@acp3bf.physik.rwth-aachen.de>
To: djgpp AT delorie DOT com
Subject: Re: emcAsc
Newsgroups: comp.os.msdos.djgpp
Organization: RWTH Aachen, III. physikalisches Institut B
X-Newsreader: TIN [version 1.2 PL2]
Reply-To: djgpp AT delorie DOT com

In article <199912020150 DOT UAA16655 AT delorie DOT com> you wrote:
> was just wondering how the fact that Emacs was coded in lisp interpreter
> affects the speed of launching emacs and its ram needs? (as compared to vim
> for example) in particular with regards to old systems like 486 sx with
> about 4 meg ram?

Why wonder about that? It's a fact of life that Emacs *is* coded in
Lisp, to a large portion. So even if that were the reason for it to be
too slow to be useful, on that small machine, you'ld not be able to do
anything about it, anyway. You *don't* want to re-implement Emacs in
raw C, trust me. Others have tried, sort of (MicroEmacs, Jove, Jed),
and they all fall short of the goal.

Actually, Lisp is conceptually a better language for a program like
Emacs, than C can ever be. Lisp lives for string operations, which are
a persistent pain in C, if you have to do many of them.

The real reason that emacs is so slow on startup is its absolute
size. It simply won't fit into 4MB RAM, without much squeezing, and as
soon as you start compilations from inside Emacs, it'll die.

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019