help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed, 21.1 vs


From: Sprenger, Karel
Subject: Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed, 21.1 vs 20)
Date: Fri, 9 Aug 2002 10:51:31 +0200

Hi,

Loading anything *is* extremely slow with emacs 21.2, and I think the reason is 
it now finally automatically places site-lisp and the complete tree under it in 
the load-path (up to version 20 one had to include these manually, although it 
was stated in the docs that emacs would do this on startup).  If you installed 
such glorious beasts as bbdb, jde and xae in the site-lisp directory (like I 
did), you'd better have a look at the resulting load-path: it's horrendous!

The result is that, when emacs starts looking for an elisp file (byt-compiled 
or plain source), it has to wade through tons of directories that only contain 
java code, html docs, or docbook stuff.  It would take me ages as well :-)

The documentation for the function normal-top-level-add-subdirs-to-load-path in 
startup.el states that it will ignore a directory containing a file .nosearch.  
This  made me wonder if this would help, even though I can't find where it is 
used (a grep for this string in emacs/lisp only produces the line with the 
defun). So I started adding an empty .nosearch file to all non-elisp 
subdirectories in my site-lisp tree (I found one already in place in the auctex 
subdirectories auto and style!), and started up another instance of emacs. It 
is amazing! It comes up with the speed of light, breezes through my 
.emacs.desktop file (restoring some 30 buffers!) and when I look at load-path 
it only has 56 instead of 441 entries!  All that I have to do now is clean up 
my own init code (in site-start.el) to remove the manual fix of load-path 
(needed in the days of old).

Hope this helps.  BTW, it would be great if Paul Kinnucan and Ovidi Predescu 
could include a .nosearch file in the distributions of their sublime packages 
(JDE+XAE, and xslt-process).

Cheers,
Karel

-----Original Message-----
From: Jeff Rancier [mailto:address@hidden
Sent: donderdag 8 augustus 2002 21:07
To: Stephen Leake; Bill Pringlemeir
Cc: address@hidden
Subject: Re: [h-e-w] ediff speed, 21.1 vs 20


I find loading anything now is extremely slow.  That is the first time.
Once ediff is loaded, it seems to work fine.
Jeff

----- Original Message -----
From: "Bill Pringlemeir" <address@hidden>
To: "Stephen Leake" <address@hidden>
Cc: <address@hidden>
Sent: Thursday, August 08, 2002 2:55 PM
Subject: Re: [h-e-w] ediff speed, 21.1 vs 20


|
|  Stephen> I've been usingn Gnu Emacs 21.1 for a few months now, and I
|  Stephen> like it.  However, it has one drawback compared to Emacs 20;
|  Stephen> ediff has slowed down tremendously, for diff sections that
|  Stephen> are multiple lines.
|
| I have experienced the same thing.
|
|  "GNU Emacs 21.2.1 (i386-msvc-nt4.0.1381) of 2002-03-19 on BILL"
|
| It seems to be related to large difference regions [at least refined
| regions].  It also finds ediff-directories finds between files with
| different line endings (Unix/DOS), but when ediff runs on the files,
| there is no difference.
|
|  Stephen> Does anyone have a clue why it slowed down so much, or how
|  Stephen> to speed it back up?
|
| I don't think that this line ending stuff happened before.  A vague
| clue?
|
|         Size   Last modified           Name
|     ----------------------------------------------
|
|     Session 1:
|         46283   Nov 30 2000 14:44:47   e:/emacs-20.7/lisp/ediff-diff.el
|         47302   Jul 21 2001 02:28:24
e:/src/emacs-21.2/lisp/ediff-diff.el
|     Session 2:
|         13584   May  4 1998 19:33:16   e:/emacs-20.7/lisp/ediff-help.el
|         13540   Jul 16 2001 04:46:48
e:/src/emacs-21.2/lisp/ediff-help.el
|     Session 3:
|         13691   May  4 1998 19:33:18   e:/emacs-20.7/lisp/ediff-hook.el
|         13828   Jul 16 2001 04:46:48
e:/src/emacs-21.2/lisp/ediff-hook.el
|     Session 4:
|         68043   Nov 11 1998 20:54:52   e:/emacs-20.7/lisp/ediff-init.el
|         69645   Sep  9 2001 19:33:38
e:/src/emacs-21.2/lisp/ediff-init.el
|     Session 5:
|         11795   May  4 1998 19:33:20   e:/emacs-20.7/lisp/ediff-merg.el
|         14487   Jul 16 2001 04:46:48
e:/src/emacs-21.2/lisp/ediff-merg.el
|     Session 6:
|         79338   May 30 1998 11:32:04   e:/emacs-20.7/lisp/ediff-mult.el
|         80375   Sep 28 2001 00:06:09
e:/src/emacs-21.2/lisp/ediff-mult.el
|     Session 7:
|         26433   Nov 30 2000 16:10:48   e:/emacs-20.7/lisp/ediff-ptch.el
|         27375   Jul 21 2001 02:28:24
e:/src/emacs-21.2/lisp/ediff-ptch.el
|     Session 8:
|        139349   May  2 2000 09:47:00   e:/emacs-20.7/lisp/ediff-util.el
|        142708   Jul 21 2001 02:28:24
e:/src/emacs-21.2/lisp/ediff-util.el
|     Session 9:
|         13492   May  4 1998 19:33:28   e:/emacs-20.7/lisp/ediff-vers.el
|         10174   Jul 16 2001 04:46:48
e:/src/emacs-21.2/lisp/ediff-vers.el
|     Session 10:
|         47005   May  4 1998 19:33:32   e:/emacs-20.7/lisp/ediff-wind.el
|         46488   Jul 16 2001 04:46:48
e:/src/emacs-21.2/lisp/ediff-wind.el
|
| After looking at all the differences, the thing that comes to mind is
| the overlays.  I think that the display updating has changed
| considerably.  Perhaps overlays and font-lock stuff were calculated
| before displaying the buffer previously.  When you whip through the
| diffs, hitting `n' for next, there are times when it pauses for a long
| time.  This was not the previous behviour... and this is the thing I
| notice.  For instance, when diffing "ediff-ptch.el", there are 32
| diffs.  When highlighting the 13th, 14th regions, I note a long pause
| (longer relative to the lavish spriteness Emacs 20.xx afforded me).
| This causes the font-lock to change the highlighting.  I think that
| this stuff is precomputed as the areas are highlighted prior to this.
| However, the area is a single color.  I don't know when the refinement
| is done, but when that region is active, there are now multiple
| colours.  Note too much help...
|
| fwiw,
| Bill Pringlemeir.
|





reply via email to

[Prev in Thread] Current Thread [Next in Thread]