Re: Accelerating Emacs?

[Herbert Euler]

> From: Eli Zaretskii <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Accelerating Emacs?
> Date: Fri, 28 Oct 2005 10:23:46 +0200

> Well, your original complaint _was_ about deleting a single
> character.  Are you on the quest to prove at all costs that Emacs is
> slow?

I am _not_ trying to prove something, I just want to know
whether it is possible to accelerate Emacs in some way,
especially in poor situation, and how.

> What kind of machine do you have there?  I tried this on a 3MB file
> (my email inbox), and it took less than 1 minute, even though I needed
> to answer the question about discarding undo info several times during
> that time.  This is on a 3GHz Pentium 4 running Windows XP.  I then
> tried the same with a 19MB email box on a 700MHz Pentium III running
> Debian GNU/Linux, and it took 13 minutes there (vim did it in 30
> seconds).  Perhaps you should upgrade your hardware?

The CPU of this machine is Pentium(R) 4 CPU 2.80 GHz, and there is
504 MB physical memory, running Windows XP and Emacs 21.3. Actually
Emacs is much more faster than vim in my first try, just replace the
beginning of each line by 4 spaces. Vim spent more than 1min finishing
this, and Emacs spent 7s only. I was so surprised while getting this
result, so I did the second, which discourages me.

Now I must show what I did. First, I wrote a Lisp program to generate
random data:

(let ((i 0))
 (while (< i 20000)
   (let ((j 0) s)
     (while (< j 10)
        (setq s (concat s (char-to-string (+ 50 (random 50))))
              j (1+ j)))
     (insert s "\n"))
   (setq i (1+ i))))

This resulted in a 235KB size file. I named it 'test', and created a bigger
file with the following command sequence:

   $ cat test >>test1
   $ cat test1 >>test
   $ cat test >>test1
   $ cat test1 >>test
   ... ...

Finally I got a file with about 8MB. I then did what I described.

> Anyway, `replace-regexp' does much more than just replace its first
> argument with the second, and those other things make it run slower.
> The doc string for `replace-regexp' says (note the last part,
> especially):
>
>     This function is usually the wrong thing to use in a Lisp program.
>     What you probably want is a loop like this:
>       (while (re-search-forward regexp nil t)
>         (replace-match to-string nil nil))
>     which will run faster and will not set the mark or print anything.

I tried this, Task Manager said Emacs were using 229 636K memory
by the time I wrote this sentence. And it spent about 5min replacing
about half (more than a half) upper case letter in the generated file.

> ??? Not unless you visit many large files, it isn't.  My Emacs session
> where I'm typing this runs for many days, has gobs of files and
> buffers in it, and still uses only 22MB of memory.

I found Emacs used more and more memory when generating random
data, so did when it replacing. These memory is released after Emacs
finishes its job. Is this because Emacs operating buffer residing in memory?

> How much memory do you have on that machine (and what OS is that)?
> Also, please tell what command you used ``to mark all text'', and what
> was the exact language of the Emacs complaint about memory.

This happens when I am testing a 100MB size file. I go to the beginning
of the file, press C-SPACE, then go to the end of the file, press M-w.
Emacs told me:

Warning: past 95% of memory limit
Killing some buffers may delay running out of memory.
However, certainly by the time you receive the 95% warning,
you should clean up, kill this Emacs, and start a new one.

If the place of pressing M-w is a bit backward, only the percentage
will be modified:

Warning: past 85% of memory limit
Killing some buffers may delay running out of memory.
However, certainly by the time you receive the 85% warning,
you should clean up, kill this Emacs, and start a new one.

And in some other case (I do not know what it is yet) it told me in the
Mini-buffer:

Memory exhausted--use M-x save-some-buffers RET

> You are entitled to decide whatever you wish, but this would be not a
> very wise decision, I think.  It is based on an unrealistic example
> (perform unrealistic replacement in an unrealistic file).  I'd advise
> against such a decision.

So perhaps I can restate it like this: if Emacs starts to be slow in
some condition, it is better of using some other tools instead of
it. And I find it very cool of running vim in Eshell.

Regards,
Guanpeng Xu

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963