[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed, 21.1
From: |
Ovidiu Predescu |
Subject: |
Re: Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed, 21.1 vs 20) |
Date: |
Fri, 09 Aug 2002 13:44:36 -0700 |
User-agent: |
Microsoft-Entourage/10.0.0.1331 |
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.
> |
>