bug#3252: 23.0.93; extremely slow to open file on windows network drive

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Sun, 10 May 2009 23:13:50 +0100
> From: Chris Withers <chris@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 11 May 2009 09:36:11 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: 3252@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

Eli Zaretskii wrote:
>> Date: Mon, 11 May 2009 09:36:11 +0100
>> From: Chris Withers <chris@simplistix.co.uk>
>> CC: 3252@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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 11 May 2009 19:11:31 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: 3252@emacsbugs.donarmstrong.com
> 
> Eli Zaretskii wrote:
> >> Date: Mon, 11 May 2009 09:36:11 +0100
> >> From: Chris Withers <chris@simplistix.co.uk>
> >> CC: 3252@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 11 May 2009 19:28:21 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: 3252@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Stefan Monnier]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 11 May 2009 23:06:10 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: 3252@emacsbugs.donarmstrong.com, Eli Zaretskii <eliz@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"?

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Sat, 16 May 2009 17:23:15 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: monnier@iro.umontreal.ca, 3252@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?

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

Eli Zaretskii wrote:
>> Date: Sat, 16 May 2009 17:23:15 +0100
>> From: Chris Withers <chris@simplistix.co.uk>
>> CC: monnier@iro.umontreal.ca, 3252@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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Lennart Borgman]

On Mon, May 18, 2009 at 12:16 PM, Chris Withers <chris@simplistix.co.uk> wrote:
> Eli Zaretskii wrote:
>>>
>>> Date: Sat, 16 May 2009 17:23:15 +0100
>>> From: Chris Withers <chris@simplistix.co.uk>
>>> CC: monnier@iro.umontreal.ca, 3252@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?)

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Jason Rumney]

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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Lennart Borgman]

On Mon, May 18, 2009 at 2:41 PM, Jason Rumney <jasonr@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?

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 18 May 2009 11:16:34 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: monnier@iro.umontreal.ca, 3252@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Eli Zaretskii]

> Date: Mon, 18 May 2009 20:13:37 +0100
> From: Chris Withers <chris@simplistix.co.uk>
> CC: monnier@iro.umontreal.ca, 3252@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.

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Stefan Monnier]

> 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

bug#3252: 23.0.93; extremely slow to open file on windows network drive

[Chris Withers]

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

bug#3252: marked as done (23.0.93; extremely slow to open file on windows network drive)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]


Your message dated Wed, 20 May 2009 20:52:26 +0800
with message-id <4A13FD0A.5070306@gnu.org>
and subject line Re: bug#3252: 23.0.93;	extremely slow to open file on windows network drive
has caused the Emacs bug report #3252,
regarding 23.0.93; extremely slow to open file on windows network drive
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3252: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3252
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3293 bytes --]

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

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



[-- Attachment #3: Type: message/rfc822, Size: 3608 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: Chris Withers <chris@simplistix.co.uk>, 3252-done@emacsbugs.donarmstrong.com
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
Message-ID: <4A13FD0A.5070306@gnu.org>

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.