GNU bug report logs - #3252
23.0.93; extremely slow to open file on windows network drive

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3252 in the body.
You can then email your comments to 3252 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.93; extremely slow to open file on windows network drive
Date: Sun, 10 May 2009 23:13:50 +0100

Opening a file on a windows share by dragging it from Explorer and 
dropping it into Emacs takes many many seconds.
Doing the same operation on Emacs 22.3.1 is almost instantaneous.
The file is in a large subversion 1.6 checkout, which may or may not be 
relevant

In GNU Emacs 23.0.93.1 (i386-mingw-nt5.1.2600)
 of 2009-05-02 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENG
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  cua-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #10 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network drive
Date: Mon, 11 May 2009 06:06:00 +0300

> Date: Sun, 10 May 2009 23:13:50 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> Cc: 
> 
> Opening a file on a windows share by dragging it from Explorer and 
> dropping it into Emacs takes many many seconds.
> Doing the same operation on Emacs 22.3.1 is almost instantaneous.
> The file is in a large subversion 1.6 checkout, which may or may not be 
> relevant

Could you try again after setting w32-get-true-file-attributes to nil?
Does that make the time shorter in any significant way?

Also, can you show some numbers, like how "many many seconds" does it
take with the current pretest and what is the time it takes Emacs 22.3
to do the same job?  And if you repeat the same task again, is the
time shorter or roughly the same?

Finally, does "C-x d" of the same directory take the same time as
drag-n-drop?

Thanks.

Message #15 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Mon, 11 May 2009 09:36:11 +0100

Eli Zaretskii wrote:
> Also, can you show some numbers, like how "many many seconds" does it
> take with the current pretest and what is the time it takes Emacs 22.3
> to do the same job?  And if you repeat the same task again, is the
> time shorter or roughly the same?

Emacs 22.3 is pretty much instantaneous.

Emacs 23.0.93 takes around 11 seconds.
Repeating the task with a different file in the same folder takes 
roughly the same time.

> Finally, does "C-x d" of the same directory take the same time as
> drag-n-drop?

No, the one file I tried took over a minute before I got bored of counting.

> Could you try again after setting w32-get-true-file-attributes to nil?
> Does that make the time shorter in any significant way?

No.

I wonder if vc-svn may be the culprit? How can I disable that?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #20 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network drive
Date: Mon, 11 May 2009 21:08:13 +0300

> Date: Mon, 11 May 2009 09:36:11 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: 3252 <at> emacsbugs.donarmstrong.com
> 
> > Finally, does "C-x d" of the same directory take the same time as
> > drag-n-drop?
> 
> No, the one file I tried took over a minute before I got bored of counting.

Sorry, I don't understand: is "C-x d" faster or slower than
drag-n-drop?

> I wonder if vc-svn may be the culprit? How can I disable that?

Try setting `vc-handled-backends' to nil.

Message #25 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Mon, 11 May 2009 19:11:31 +0100

Eli Zaretskii wrote:
>> Date: Mon, 11 May 2009 09:36:11 +0100
>> From: Chris Withers <chris <at> simplistix.co.uk>
>> CC: 3252 <at> emacsbugs.donarmstrong.com
>>
>>> Finally, does "C-x d" of the same directory take the same time as
>>> drag-n-drop?
>> No, the one file I tried took over a minute before I got bored of counting.
> 
> Sorry, I don't understand: is "C-x d" faster or slower than
> drag-n-drop?

Slower.

>> I wonder if vc-svn may be the culprit? How can I disable that?
> 
> Try setting `vc-handled-backends' to nil.

The gave me the following error on startup:

Warning (initialization): An error occurred while loading `~/.emacs':

Wrong type argument: symbolp, (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch)

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #30 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network drive
Date: Mon, 11 May 2009 21:25:15 +0300

> Date: Mon, 11 May 2009 19:11:31 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: 3252 <at> emacsbugs.donarmstrong.com
> 
> Eli Zaretskii wrote:
> >> Date: Mon, 11 May 2009 09:36:11 +0100
> >> From: Chris Withers <chris <at> simplistix.co.uk>
> >> CC: 3252 <at> emacsbugs.donarmstrong.com
> >>
> >>> Finally, does "C-x d" of the same directory take the same time as
> >>> drag-n-drop?
> >> No, the one file I tried took over a minute before I got bored of counting.
> > 
> > Sorry, I don't understand: is "C-x d" faster or slower than
> > drag-n-drop?
> 
> Slower.

Ah, now I get it: you need to wait 11 seconds for visiting
_a_single_file_ in that directory, is that right?

> >> I wonder if vc-svn may be the culprit? How can I disable that?
> > 
> > Try setting `vc-handled-backends' to nil.
> 
> The gave me the following error on startup:
> 
> Warning (initialization): An error occurred while loading `~/.emacs':
> 
> Wrong type argument: symbolp, (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch)

Try in 'emacs -Q".  After invoking "emacs -Q", manually set
`vc-handled-backends' to nil, and then drag-n-drop that file.

And trying this in "emacs -Q" is a good idea anyway, since the source
of the slowdown may be in your ~/.emacs.

Message #35 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Mon, 11 May 2009 19:28:21 +0100

Eli Zaretskii wrote:
>>>>> Finally, does "C-x d" of the same directory take the same time as
>>>>> drag-n-drop?
>>>> No, the one file I tried took over a minute before I got bored of counting.
>>> Sorry, I don't understand: is "C-x d" faster or slower than
>>> drag-n-drop?
>> Slower.
> 
> Ah, now I get it: you need to wait 11 seconds for visiting
> _a_single_file_ in that directory, is that right?

No, the 11 seconds is for dragging and dropping a single file from 
Windows Explorer into Emacs.

For a single file in that directory using C-x d, I waited for over a 
minute and then gave up counting. The file did eventually open some time 
later...

> Try in 'emacs -Q".  After invoking "emacs -Q", manually set
> `vc-handled-backends' to nil, and then drag-n-drop that file.
> 
> And trying this in "emacs -Q" is a good idea anyway, since the source
> of the slowdown may be in your ~/.emacs.

My .emacs is pretty sparse nowadays ;-)

What does emacs -Q mean? How do I do this on Windows? runemacs.exe -Q in 
a DOS box or something else?

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #40 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network drive
Date: Mon, 11 May 2009 21:41:03 +0300

> Date: Mon, 11 May 2009 19:28:21 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: 3252 <at> emacsbugs.donarmstrong.com
> 
> What does emacs -Q mean?

It disables all customizations and in particular does not load your
~/.emacs init file.

> How do I do this on Windows? runemacs.exe -Q in a DOS box or
> something else?

Yes, "runemacs -Q" in a DOS box.

Message #45 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network drive
Date: Mon, 11 May 2009 17:15:15 -0400

>> Try setting `vc-handled-backends' to nil.

> The gave me the following error on startup:

> Warning (initialization): An error occurred while loading `~/.emacs':

> Wrong type argument: symbolp, (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch)

What Eli meant to say is

  (setq vc-handled-backends nil)
not
  (set vc-handled-backends nil)


        Stefan

Message #50 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3252 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Mon, 11 May 2009 23:06:10 +0100

Stefan Monnier wrote:
>>> Try setting `vc-handled-backends' to nil.
> 
>> The gave me the following error on startup:
> 
>> Warning (initialization): An error occurred while loading `~/.emacs':
> 
>> Wrong type argument: symbolp, (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch)
> 
> What Eli meant to say is
> 
>   (setq vc-handled-backends nil)

With this, drag'n'drop time isstil about 8 seconds, and C-X d time is 
about 12 seconds.

I guess it must be something else then...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #55 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Tue, 12 May 2009 00:49:11 -0400

> Date: Mon, 11 May 2009 23:06:10 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: 3252 <at> emacsbugs.donarmstrong.com, Eli Zaretskii <eliz <at> gnu.org>
> 
> >   (setq vc-handled-backends nil)
> 
> With this, drag'n'drop time isstil about 8 seconds, and C-X d time is 
> about 12 seconds.
> 
> I guess it must be something else then...

I guess it is.

How large is the file, and what's in it?  Is it plain ASCII text or
does it have non-ASCII characters? if the latter, can you tell more
about the contents?

What mode does Emacs turn on when you visit that file?

Next, can you copy the file to your local filesystem and visit it from
there?  If you do, how much time does it take then?

Finally, is the time to visit the file with "C-x C-f" comparable with
the time needed when you drag-n-drop it?  How about the time to visit
it with "M-x find-file-literally RET"?

Message #60 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Sat, 16 May 2009 17:23:15 +0100

Eli Zaretskii wrote:
> How large is the file, and what's in it?  Is it plain ASCII text or
> does it have non-ASCII characters? if the latter, can you tell more
> about the contents?

It's a 12kB .py file...

> What mode does Emacs turn on when you visit that file?

Python Mode, but it doesn't matter, same problem if I open a similarly 
small text file.

> Next, can you copy the file to your local filesystem and visit it from
> there? 

Yes.

> If you do, how much time does it take then?

Instantaneous.

> Finally, is the time to visit the file with "C-x C-f" comparable with
> the time needed when you drag-n-drop it? 

Yes, it's just as slow.

> How about the time to visit
> it with "M-x find-file-literally RET"?

No, this is instantaneous.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #65 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network drive
Date: Sat, 16 May 2009 20:48:02 +0300

> Date: Sat, 16 May 2009 17:23:15 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: monnier <at> iro.umontreal.ca, 3252 <at> emacsbugs.donarmstrong.com
> 
> > How about the time to visit
> > it with "M-x find-file-literally RET"?
> 
> No, this is instantaneous.

Is "M-x find-file-literally RET" instantaneous when the file is on the
networked drive as well?

Message #70 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Mon, 18 May 2009 11:16:34 +0100

Eli Zaretskii wrote:
>> Date: Sat, 16 May 2009 17:23:15 +0100
>> From: Chris Withers <chris <at> simplistix.co.uk>
>> CC: monnier <at> iro.umontreal.ca, 3252 <at> emacsbugs.donarmstrong.com
>>
>>> How about the time to visit
>>> it with "M-x find-file-literally RET"?
>> No, this is instantaneous.
> 
> Is "M-x find-file-literally RET" instantaneous when the file is on the
> networked drive as well?

Yes

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #75 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chris Withers <chris <at> simplistix.co.uk>, 3252 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network 
	drive
Date: Mon, 18 May 2009 12:37:08 +0200

On Mon, May 18, 2009 at 12:16 PM, Chris Withers <chris <at> simplistix.co.uk> wrote:
> Eli Zaretskii wrote:
>>>
>>> Date: Sat, 16 May 2009 17:23:15 +0100
>>> From: Chris Withers <chris <at> simplistix.co.uk>
>>> CC: monnier <at> iro.umontreal.ca, 3252 <at> emacsbugs.donarmstrong.com
>>>
>>>> How about the time to visit
>>>> it with "M-x find-file-literally RET"?
>>>
>>> No, this is instantaneous.
>>
>> Is "M-x find-file-literally RET" instantaneous when the file is on the
>> networked drive as well?
>
> Yes

Could it be that Emacs has the wrong default directory internally when
searching for some files? (Perhaps fonts?)

Message #80 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>,
        3252 <at> debbugs.gnu.org
Cc: Chris Withers <chris <at> simplistix.co.uk>
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
  drive
Date: Mon, 18 May 2009 20:41:41 +0800

Lennart Borgman wrote:
> Could it be that Emacs has the wrong default directory internally when
> searching for some files? (Perhaps fonts?)
>   

Emacs doesn't search for fonts directly on Windows. I am pretty sure 
Windows itself only searches in a fixed location for fonts, otherwise 
other applications would have the same slowdown whenever they enumerate 
fonts when the default directory is a network drive.

Message #85 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 3252 <at> debbugs.gnu.org, Chris Withers <chris <at> simplistix.co.uk>
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network 
	drive
Date: Mon, 18 May 2009 14:49:19 +0200

On Mon, May 18, 2009 at 2:41 PM, Jason Rumney <jasonr <at> gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> Could it be that Emacs has the wrong default directory internally when
>> searching for some files? (Perhaps fonts?)
>>
>
> Emacs doesn't search for fonts directly on Windows. I am pretty sure Windows
> itself only searches in a fixed location for fonts, otherwise other
> applications would have the same slowdown whenever they enumerate fonts when
> the default directory is a network drive.

But maybe only Emacs handles the default directory in a way that might
interfere?

Message #90 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network drive
Date: Mon, 18 May 2009 21:19:13 +0300

> Date: Mon, 18 May 2009 11:16:34 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: monnier <at> iro.umontreal.ca, 3252 <at> emacsbugs.donarmstrong.com
> 
> >>> How about the time to visit
> >>> it with "M-x find-file-literally RET"?
> >> No, this is instantaneous.
> > 
> > Is "M-x find-file-literally RET" instantaneous when the file is on the
> > networked drive as well?
> 
> Yes

OK.  I asked before, but I don't think you answered: does this file
include non-ASCII characters?

Also, what happens if you use "C-x C-f" to visit an identical file on
the networked drive, but whose name ends with a .txt extension? do you
see any significant change in the time it takes?  If visiting a .txt
file is also instantaneous, then please tell what version of Python
mode do you use.

Message #95 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Mon, 18 May 2009 20:13:37 +0100

Eli Zaretskii wrote:
>>> Is "M-x find-file-literally RET" instantaneous when the file is on the
>>> networked drive as well?
>> Yes
> 
> OK.  I asked before, but I don't think you answered: does this file
> include non-ASCII characters?

No, it doesn't.

> Also, what happens if you use "C-x C-f" to visit an identical file on
> the networked drive, but whose name ends with a .txt extension? 

Interestingly, that's prettymuch instantaneous, as it should be.
However, a .cfg file (which openis in Conf[unix]) mode is just as slow 
as the .py file.

> see any significant change in the time it takes?  If visiting a .txt
> file is also instantaneous, then please tell what version of Python
> mode do you use.

I use whatever ships with 23.0.93. How can I check the version for definite?
Also, what mode is used to open .cfg files?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #100 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: monnier <at> iro.umontreal.ca, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network drive
Date: Mon, 18 May 2009 23:31:29 +0300

> Date: Mon, 18 May 2009 20:13:37 +0100
> From: Chris Withers <chris <at> simplistix.co.uk>
> CC: monnier <at> iro.umontreal.ca, 3252 <at> emacsbugs.donarmstrong.com
> 
> > Also, what happens if you use "C-x C-f" to visit an identical file on
> > the networked drive, but whose name ends with a .txt extension? 
> 
> Interestingly, that's prettymuch instantaneous, as it should be.
> However, a .cfg file (which openis in Conf[unix]) mode is just as slow 
> as the .py file.

Can you try using elp.el to profile python.el and conf-mode.el in the
slow cases?  The instructions are at the beginning of elp.el.

> > see any significant change in the time it takes?  If visiting a .txt
> > file is also instantaneous, then please tell what version of Python
> > mode do you use.
> 
> I use whatever ships with 23.0.93. How can I check the version for definite?

If you are sure you are using python.el that comes with Emacs 23.0.93
and that there's no stray python-SOMETHING.el on your load-path, then
no need to dig deeper.

> Also, what mode is used to open .cfg files?

conf-mode.el, I'd presume.

Message #105 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network drive
Date: Mon, 18 May 2009 22:12:45 -0400

> Interestingly, that's prettymuch instantaneous, as it should be.
> However, a .cfg file (which openis in Conf[unix]) mode is just as slow as
> the .py file.

Great: the mode used for .cfg files is much simpler than for Python
files, so it should make it easier to find the problem.

What happens if you enable "Options => Enter Debugger on Quit/C-g" in
the menu and than hit C-g during the 10s delay (try it at different
moments of this 10s window, to see if/how the resulting backtrace
changes)?


        Stefan

Message #110 received at 3252 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 3252 <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93; extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 11:35:04 +0100

Stefan Monnier wrote:
>> Interestingly, that's prettymuch instantaneous, as it should be.
>> However, a .cfg file (which openis in Conf[unix]) mode is just as slow as
>> the .py file.
> 
> Great: the mode used for .cfg files is much simpler than for Python
> files, so it should make it easier to find the problem.
> 
> What happens if you enable "Options => Enter Debugger on Quit/C-g" in
> the menu and than hit C-g during the 10s delay (try it at different
> moments of this 10s window, to see if/how the resulting backtrace
> changes)?

Okay, I enabled the debugger as requested, on trying to drag and drop, 
hitting C-g just cause the bell to sound, nothing happened and the delay 
wasn't interrupted. In fact, when the file was eventually opened, the 
debugger didn't even pick up and give me a backtrace.

Opening another .cfg file with C-x C-f also had a bit of the 
bell-not-debugger problem when hitting C-g, but it did eventually give 
me the following backtrace:

Debugger entered--Lisp error: (quit)
  locate-dominating-file("//Server2/chris/folder/file.cfg" 
".dir-locals.el")
  dir-locals-find-file("//Server2/chris/folder/file.cfg")
  hack-dir-local-variables()
  hack-local-variables()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer buildout.cfg> 
"//Server2/chris/folder/file.cfg" nil nil 
"//Server2/chris/folder/file.cfg" ((134283655 . 49251) 105972995))
  find-file-noselect("../buildout.cfg" nil nil t)
  find-file("../buildout.cfg" t)
  call-interactively(find-file nil nil)

cheers,

Chris - be warned, I know no lisp ;-)

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #115 received at 3252-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>,
        3252-done <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 20:52:26 +0800

Chris Withers wrote:
> Debugger entered--Lisp error: (quit)
>   locate-dominating-file("//Server2/chris/folder/file.cfg" 
> ".dir-locals.el")

Thanks, there was a / missing from the regexp in 
locate-dominating-stop-dir-regexp, so the search wasn't actually 
terminating at the root of UNC drives, instead a fruitless and time 
consuming search for a machine on the network called ".dir-locals.el" 
would occur.

Message #116 received at 3252-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 3252-done <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 14:00:27 +0100

Jason Rumney wrote:
> Chris Withers wrote:
>> Debugger entered--Lisp error: (quit)
>>   locate-dominating-file("//Server2/chris/folder/file.cfg" 
>> ".dir-locals.el")
> 
> Thanks, there was a / missing from the regexp in 
> locate-dominating-stop-dir-regexp, so the search wasn't actually 
> terminating at the root of UNC drives, instead a fruitless and time 
> consuming search for a machine on the network called ".dir-locals.el" 
> would occur.

Interesting.

Does Emacs have an automated unit test suite?
The last couple of bugs I've filed all appear to have been funny little 
things like this which I'd expect unit tests to catch...

Anyway, what version of emacs 23 will this fix land in and when will it 
be released?

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #117 received at 3252-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252-done <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 21:09:29 +0800

Chris Withers wrote:
> Interesting.
>
> Does Emacs have an automated unit test suite?
> The last couple of bugs I've filed all appear to have been funny 
> little things like this which I'd expect unit tests to catch...


There is nothing magic about automated test suites that makes them catch 
bugs like this. Someone still needs to write the test cases and 
configure machines, and in this case networks, to run them.

Message #118 received at 3252-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chris Withers <chris <at> simplistix.co.uk>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 3252-done <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 14:12:25 +0100

Jason Rumney wrote:
> Chris Withers wrote:
>> Interesting.
>>
>> Does Emacs have an automated unit test suite?
>> The last couple of bugs I've filed all appear to have been funny 
>> little things like this which I'd expect unit tests to catch...
> 
> There is nothing magic about automated test suites that makes them catch 
> bugs like this. Someone still needs to write the test cases and 
> configure machines, and in this case networks, to run them.

I'll take that as a "no" then ;-)

What about a release date?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

Message #119 received at 3252-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: Chris Withers <chris <at> simplistix.co.uk>
Cc: 3252-done <at> debbugs.gnu.org
Subject: Re: bug#3252: 23.0.93;	extremely slow to open file on windows network
 drive
Date: Wed, 20 May 2009 21:26:04 +0800

Chris Withers wrote:
> Jason Rumney wrote:
>> There is nothing magic about automated test suites that makes them 
>> catch bugs like this. Someone still needs to write the test cases and 
>> configure machines, and in this case networks, to run them.
>
> I'll take that as a "no" then ;-)

Not quite a no; 
http://cvs.savannah.gnu.org/viewvc/emacs/test/README?root=emacs&view=markup

But the point that someone needs to write the test cases still stands, 
as in a little over a year there are still only tests for the byte 
compiler's handling of arithmetic functions, icalendar.el and parts of 
newsticker.el

> What about a release date?

23.0.94 is due to be released today, but I don't know if my checkin was 
already too late to make the release.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.