[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: |
Jeff Rancier |
|
Subject: |
Re: Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed, 21.1 vs 20) |
|
Date: |
Mon, 12 Aug 2002 16:55:28 -0400 |
I tried Karel's suggestion, and it works like a charm. I massaged some
example code from ERH's Java I/O book, and came up with the following Java
app. It walks a directory tree, searching for .el and .elc files, then it
goes through a deposits a .nosearch file in the appropriate directories.
Since it recursively walks the directories, it needs to check every file,
ensuring we don't miss a subdirectory.
One interesting thing which I don't quite understand is when using the
java.util.regex utilities, I don't seem to get a match when the two
directories I was comparing are *identical*. I added in a
String.equalsIgnoreCase() method call to augment the Matcher. I'm sure it's
something with my regex.
I was able to reload emacs in less than 5 minutes, where it's been take up
to 15. It also skips directories with only a JDE project file in it. That
certainly doesn't need to be in the load-path.
(NOTE: You'll need to change the path to touch.exe.)
The code:
import java.io.*;
import java.util.*;
import java.util.regex.*;
public class DirList implements FilenameFilter
{
File directory;
static Vector seen = new Vector();
static Vector lispFiles = new Vector();
static Vector nonLispFiles = new Vector();
public static void main(String[] args)
{
try
{
for (int i = 0; i < args.length; i++)
{
DirList dl = new DirList(args[i]);
dl.list();
}
for ( int i = 0 ; i < nonLispFiles.size() ; i++ )
{
try
{
for ( int j = 0 ; j < lispFiles.size() ; j++ )
{
String lispDir = lispFiles.get( j ).toString();
String nonLispDir = nonLispFiles.get(
i ).toString();
lispDir = lispDir.replaceAll( "\\\\", "/" );
nonLispDir = nonLispDir.replaceAll( "\\\\", "/" );
System.out.println( "Is [" + nonLispDir + "] a
substring of [" +
lispDir + "] ?" );
Pattern p = Pattern.compile( nonLispDir + ".+",
Pattern.CASE_INSENSITIVE );
if ( lispDir.equalsIgnoreCase( nonLispDir) )
System.out.println( "They're EQUAL" );
else
System.out.println( "They're NOT EQUAL" );
Matcher m = p.matcher( lispDir );
if ( m.matches() || lispDir.equalsIgnoreCase(
nonLispDir) )
{
System.out.println( "Removing " +
nonLispFiles.get(i).toString() );
nonLispFiles.removeElementAt( i );
}
}
}
catch ( PatternSyntaxException e )
{
System.out.println( "Invalid Pattern Syntax [" +
e.getPattern() + "]" );
System.out.println( e.getMessage() );
System.exit( 1 );
}
}
System.out.println(
"---------------------------------------------" );
System.out.println( "Directories containing elisp code." );
System.out.println(
"---------------------------------------------" );
for ( int i = 0 ; i < lispFiles.size() ; i++ )
System.out.println( lispFiles.get( i ).toString() );
System.out.println(
"---------------------------------------------" );
System.out.println( "Directories not containing elisp code." );
System.out.println(
"---------------------------------------------" );
for ( int i = 0 ; i < nonLispFiles.size() ; i++ )
{
String command = new String( "t:/bin/touch.exe " +
nonLispFiles.get(
i ).toString() +
"\\.nosearch" );
System.out.println( nonLispFiles.get( i ).toString() );
//System.out.println( command );
Runtime rt = Runtime.getRuntime();
try
{
Process p = rt.exec( command );
p.waitFor();
//System.out.println( "exitValue [" + p.exitValue() +
"]" );
InputStream es = p.getErrorStream();
}
catch (IOException e)
{
System.out.println( "IOExeception:: rt.exec()");
}
catch ( InterruptedException e)
{
System.out.println( "InterruptedException::
p.waitFor()");
}
}
}
catch (IOException e)
{
System.err.println(e);
}
}
public DirList(String s) throws IOException
{
this(new File(s));
}
public DirList(File directory) throws IOException
{
if (directory.isDirectory())
{
this.directory = new File(directory.getCanonicalPath());
}
else
{
throw new IOException(directory.toString() + " is not a
directory");
}
}
public boolean accept( File dir, String name )
{
boolean isAccepted = false;
try
{
Pattern p = Pattern.compile( "^.+\\.elc?$",
Pattern.CASE_INSENSITIVE );
Matcher m = p.matcher( name );
if ( m.matches() )
{
System.out.println( "Found [" + name + "] in [" +
dir.toString() + "]" );
if ( !name.equalsIgnoreCase( "prj.el") )
isAccepted = true;
}
}
catch ( PatternSyntaxException e )
{
System.out.println( "Invalid Pattern Syntax [" + e.getPattern()
+ "]" );
System.out.println( e.getMessage() );
System.exit( 1 );
}
return isAccepted;
}
public void list() throws IOException
{
if (!seen.contains(this.directory))
{
seen.addElement(this.directory);
String[] files = directory.list();
for (int i = 0; i < files.length; i++)
{
File f = new File(directory, files[i]);
if (f.isFile())
{
if ( accept( this.directory, f.getName() ))
{
if ( !lispFiles.contains( this.directory ))
lispFiles.addElement( this.directory );
}
else
{
if ( !nonLispFiles.contains( this.directory ))
nonLispFiles.addElement( this.directory );
}
}
else
{ // it's another directory
DirList dl = new DirList(f);
dl.list();
}
}
}
else
{
System.out.println( this.directory + "Already in vector" );
}
}
}
Jeff
|
| ----- Original Message -----
| From: "Sprenger, Karel" <address@hidden>
| To: "Jeff Rancier" <address@hidden>
| Sent: Saturday, August 10, 2002 1:14 PM
| Subject: RE: Emacs 21's slow loading of things (was RE: [h-e-w] ediff
speed,
| 21.1 vs 20)
|
|
| | Hi,
| |
| | With Jeff's example tree:
| | /usr
| | /usr/home
| | /usr/home/jrancier
| | /usr/home/jrancier/foo
| | /usr/home/jrancier/foo/bar
| | /usr/home/jrancier/foo/etc
| | /usr/home/jrancier/java
| |
| | with lisp files in /usr/home/jrancier/foob/bar but not in
| /usr/home/jrancier/foo/etc and certainly not in /usr/home/jrancier/java,
you
| would place .nosearch files in /usr/home/jrancier/foo/etc and
| /usr/home/jrancier/java. The more productive .nosearch files (they can be
| empty, i.e., just run 'touch .nosearch' if you have a touch program
| available) will be those in the /emacs/site-lisp subdirectories for JDE,
XAE
| and xslt-process as I explained in yesterday's post. Also, don't forget
to
| remove any adjustments of load-path that were needed in old times as they
| now cause the "manually" added directories to appear twice in load-path.
| |
| | Cheers,
| | Karel
| |
| | -----Original Message-----
| | From: Jeff Rancier [mailto:address@hidden
| | Sent: vrijdag 9 augustus 2002 22:27
| | To: Sprenger, Karel
| | Subject: Re: Emacs 21's slow loading of things (was RE: [h-e-w] ediff
| | speed, 21.1 vs 20)
| |
| |
| | It takes me close to 15 minutes for me to load! Problems with ange-ftp
| and
| | ECB force me to restart on occasion to make it worse. Talk about
| | unproductive.
| |
| | Is there more reading? I guess my question is whether emacs stops in
the
| | directory tree at that point, or just stops reading the current
directory?
| | E.g.
| |
| | given the following:
| |
| | /usr
| | /usr/home
| | /usr/home/jrancier
| | /usr/home/jrancier/foo
| | /usr/home/jrancier/foo/bar
| | /usr/home/jrancier/foo/etc
| | /usr/home/jrancier/java
| |
| | If we have a <.nosearch> in foo, but lisp files in bar, does emacs
search
| | bar and etc? Or just move on to java?
| |
| | Jeff
| | ----- Original Message -----
| | From: "Sprenger, Karel" <address@hidden>
| | To: "Jeff Rancier" <address@hidden>; "Stephen Leake"
| | <address@hidden>; "Bill Pringlemeir"
| | <address@hidden>
| | Cc: <address@hidden>; "Paul Kinnucan" <address@hidden>;
| | "Ovidi Predescu" <address@hidden>
| | Sent: Friday, August 09, 2002 4:51 AM
| | Subject: Emacs 21's slow loading of things (was RE: [h-e-w] ediff speed,
| | 21.1 vs 20)
| |
| |
| | | 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.
| | | |
| | |