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

[Ovidiu Predescu]

Karel,

I'm not familiar with the .nosearch file. Should it be a simple, empty file,
in each of the directories that don't need to be searched?

Thanks,
Ovidiu

On 8/9/02 1:51 AM, "Sprenger, Karel" <address@hidden> wrote:

> 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.
> |
>