GNU bug report logs - #5833
23.1.94; Opening files on network shares on w32 is slow

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 5833 in the body.
You can then email your comments to 5833 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1.94; Opening files on network shares on w32 is slow
Date: Sat, 3 Apr 2010 23:16:48 +0200

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

I did this:

emacs -Q
C-x C-f //some_server/some_share/ RET
Then, on some file in Dired, opened a file with f or RET.

This operation is much slower than the same operation done using
Notepad. For a file about 80 KB in size it takes about one second in
Notepad and 5-6 seconds in Emacs.

I have tried some tips found in old threads about this, like turning off
some vc-parameter and some parameter controlling whether extra
properties should be fetched (or something like that) for shares. No
effect though. Opening local files is blazingly fast.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/pgm/emacs/etc/DEBUG.


In GNU Emacs 23.1.94.1 (i386-mingw-nt5.1.2600)
 of 2010-03-23 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/imagesupport/include'

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: SVE
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Dired by name

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

Recent input:
C-x C-f C-y <return> <down> <down> <down> <return>
<down-mouse-1> <mouse-1> M-: C-y <return> q M-: C-y
<home> <right> <right> <right> <right> q <end> <return>
C-x k <return> <up> <up> <return> <f5> <down> <up>
<down> C-x k <return> M-x f i n d SPC f i l <tab> SPC
l i <tab> <return> 5 1 0 0 <tab> <return> C-x k <return>
<help-echo> <down> <down> <down> <down> <down> <down>
<down> <down> <down> <down> <down> <down> <down> <down>
<down> <down> C C-a C-k c Ö - <backspace> <backspace>
: / m u u . t x t <return> C-x C-f <up> <return> <f5>
<down> <up> C-x k <return> C-h c f f C-x k <return>
<lwindow> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Entering debugger...
Back to top level.
nil
Copy: 1 of 1
Copy: 1 file
f runs the command dired-find-file

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug dired-aux help-mode easymenu view
debug dired regexp-opt tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process multi-tty
emacs)

Message #8 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Sun, 04 Apr 2010 09:00:12 +0300

> From: Mathias Dahl <mathias.dahl <at> gmail.com>
> Date: Sat, 3 Apr 2010 23:16:48 +0200
> Cc: 
> 
> emacs -Q
> C-x C-f //some_server/some_share/ RET
> Then, on some file in Dired, opened a file with f or RET.
> 
> This operation is much slower than the same operation done using
> Notepad. For a file about 80 KB in size it takes about one second in
> Notepad and 5-6 seconds in Emacs.

Does it help to set w32-get-true-file-attributes to a nil value?

Also, is this a regression in the last pretest?  IOW, when was the
last time you tried visiting files on that remote file system and it
was much faster than what you see now with 23.1.94?

Thanks.

Message #11 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 5 Apr 2010 13:35:44 +0200

Hi, Eli, thanks for looking into this!

> Does it help to set w32-get-true-file-attributes to a nil value?

No.

> Also, is this a regression in the last pretest?  IOW, when was the
> last time you tried visiting files on that remote file system and it
> was much faster than what you see now with 23.1.94?

As far as I can see this has been slow for quite a while. I have
recently reinstalled my PC so I don't have the old versions with me. I
downloaded 22.3 and it was even slower.

Last year (I think it was) I reported a similar issue, which was
fixed. That performance issue could be worked around by setting the
variable above. That problem was even worse though.

The reason I have noticed this at all is that one of our servers has
moved to another office lately, so the network of course plays a role
in this. However, there is still the question what Emacs does that
Notepad don't (well, I know, a lot, but computers are fast nowadays)
that makes for the difference in opening files on shares (it could be
a problem locally as well but maybe it is so fast that I don't
notice).

Just now I tested this scenario in the latest pretest: I opened (from
Dired) a file only 800 bytes in size. It took 7 seconds. I then opened
another file, over 100 000 bytes and that also took 7 seconds. Opening
the larger of the files in Notepad takes just above a second.

If there are any other tests I can do, please let me know. I currently
don't have a way to compile the source myself on w32, just so that you
know.

Thanks!

/Mathias

Message #14 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 05 Apr 2010 15:33:40 +0300

> From: Mathias Dahl <mathias.dahl <at> gmail.com>
> Date: Mon, 5 Apr 2010 13:35:44 +0200
> Cc: 5833 <at> debbugs.gnu.org
> 
> Just now I tested this scenario in the latest pretest: I opened (from
> Dired) a file only 800 bytes in size. It took 7 seconds. I then opened
> another file, over 100 000 bytes and that also took 7 seconds. Opening
> the larger of the files in Notepad takes just above a second.

7 seconds is an eternity for such small files.

Btw, is "C-x C-f" faster than Dired, by any chance?

> If there are any other tests I can do, please let me know.

Can you tell if setting the following variables has any effect?

  (setq vc-handled-backends nil)
  (setq locate-dominating-stop-dir-regexp "")

(Please try them one by one, in that order.)

Message #17 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 5 Apr 2010 20:15:47 +0200

> 7 seconds is an eternity for such small files.

I know :)

> Btw, is "C-x C-f" faster than Dired, by any chance?

No, at least not enough to be measured with a stop watch.

> Can you tell if setting the following variables has any effect?
>
>  (setq vc-handled-backends nil)

From having taken close to 8 seconds (tried repeatedly), after this
change it takes almost 6, so 2 s better. Still a long time, but
better.

>  (setq locate-dominating-stop-dir-regexp "")

That maybe shaves off half a second. Again, hard to done any
scientific tests using a physical stop watch.

/Mathias

Message #20 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 05 Apr 2010 16:15:14 -0400

>>  (setq locate-dominating-stop-dir-regexp "")
> That maybe shaves off half a second.

Hmm... odd.  That seemed like a pretty good guess
(locate-dominating-file tends to suffer from such performance problems
in some cases, and vc-handled-backends is one user of this function,
and dir-locals is another, so setting locate-dominating-stop-dir-regexp
should really kill it off).

> Again, hard to done any scientific tests using a physical stop watch.

That's OK.  When we find the culprit, it should bring the time down to
something significantly lower: no need for a stopwatch.


        Stefan

Message #23 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 5 Apr 2010 23:03:55 +0200

> That's OK.  When we find the culprit, it should bring the time down to
> something significantly lower: no need for a stopwatch.

Instead of using my stop watch I wrote a small elisp program (slow.el)
to measure the time for me:

(defun measure ()
  (dotimes (i 10)
    (let ((time1 (float-time))
	  time2)
      (find-file "//corpnet/files/Archive/Archive75/docman/core/docman
5.11.0/docman/database/docman/index.cre")
      (setq time2 (float-time))
      (kill-buffer)
      (message "Time elapsed: %s" (- time2 time1)))))

(message "emacs -Q")
(measure)
(message "(setq vc-handled-backends nil)")
(setq vc-handled-backends nil)
(measure)
(message "(setq locate-dominating-stop-dir-regexp \"\")")
(setq locate-dominating-stop-dir-regexp "")
(measure)

I started Emacs with -Q -l slow.el

These are the results:

emacs -Q
Time elapsed: 7.5309998989105225
Time elapsed: 5.156000137329102
Time elapsed: 7.266000032424927
Time elapsed: 4.641000032424927
Time elapsed: 4.952999830245972
Time elapsed: 7.391000032424927
Time elapsed: 4.75
Time elapsed: 4.828000068664551
Time elapsed: 7.25
Time elapsed: 4.687000036239624
(setq vc-handled-backends nil)
Time elapsed: 2.7659997940063477
Time elapsed: 5.125
Time elapsed: 2.4690001010894775
Time elapsed: 2.4839999675750732
Time elapsed: 2.7350001335144043
Time elapsed: 4.7809998989105225
Time elapsed: 2.8589999675750732
Time elapsed: 2.5160000324249268
Time elapsed: 2.6089999675750732
Time elapsed: 5.266000032424927
(setq locate-dominating-stop-dir-regexp "")
Time elapsed: 2.187999963760376
Time elapsed: 1.937000036239624
Time elapsed: 1.9219999313354492
Time elapsed: 2.0160000324249268
Time elapsed: 4.5
Time elapsed: 1.9060001373291016
Time elapsed: 2.0159997940063477
Time elapsed: 2.078000068664551
Time elapsed: 1.9060001373291016
Time elapsed: 1.9059998989105225

The file to open is 801 bytes in size.

No result is as bad as when I do RET in Dired, but maybe that is
natural (maybe Emacs skips the redisplay). Right after the test above
I did that and got the times 5, 5, 3, 5, 5 and 5 seconds,
respectively. I again tested a few times with C-x C-f but there was no
difference.

The same test with another file in the same dir that has the size
113226 gives these results:

emacs -Q
Time elapsed: 7.578000068664551
Time elapsed: 5.141000032424927
Time elapsed: 5.014999866485596
Time elapsed: 7.391000032424927
Time elapsed: 4.812999963760376
Time elapsed: 5.062000036239624
Time elapsed: 7.812999963760376
Time elapsed: 4.733999967575073
Time elapsed: 7.375
Time elapsed: 5.937999963760376
(setq vc-handled-backends nil)
Time elapsed: 5.234000205993652
Time elapsed: 2.671999931335449
Time elapsed: 2.578000068664551
Time elapsed: 2.8439998626708984
Time elapsed: 5.046999931335449
Time elapsed: 2.7660000324249268
Time elapsed: 3.015000104904175
Time elapsed: 2.671999931335449
Time elapsed: 5.141000032424927
Time elapsed: 2.578000068664551
(setq locate-dominating-stop-dir-regexp "")
Time elapsed: 2.062999963760376
Time elapsed: 2.0149998664855957
Time elapsed: 2.2350001335144043
Time elapsed: 4.796999931335449
Time elapsed: 2.1089999675750732
Time elapsed: 2.125
Time elapsed: 2.0
Time elapsed: 2.0470001697540283
Time elapsed: 4.483999967575073
Time elapsed: 2.296999931335449

Slower but not in relation to the file size.

Anyway, maybe the numbers will say something to you.

/Mathias

Message #26 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Tue, 06 Apr 2010 00:58:39 +0300

> From: Mathias Dahl <mathias.dahl <at> gmail.com>
> Date: Mon, 5 Apr 2010 20:15:47 +0200
> Cc: 5833 <at> debbugs.gnu.org
> 
> > Btw, is "C-x C-f" faster than Dired, by any chance?
> 
> No, at least not enough to be measured with a stop watch.
> 
> > Can you tell if setting the following variables has any effect?
> >
> >  (setq vc-handled-backends nil)
> 
> From having taken close to 8 seconds (tried repeatedly), after this
> change it takes almost 6, so 2 s better. Still a long time, but
> better.
> 
> >  (setq locate-dominating-stop-dir-regexp "")
> 
> That maybe shaves off half a second. Again, hard to done any
> scientific tests using a physical stop watch.

That's strange: I thought they would slash much more.

How about insert-file-contents and insert-file-contents-literally --
can you time those?

Another idea is to use elp.el to profile the various functions called
by find-file.  At least for the Lisp level, we will see where's the
bottleneck, and that might give some ideas.

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> f2s.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Tue, 06 Apr 2010 08:12:22 +0800

On 06/04/2010 04:15, Stefan Monnier wrote:
>>>   (setq locate-dominating-stop-dir-regexp "")
>>>        
>> That maybe shaves off half a second.
>>      
> Hmm... odd.  That seemed like a pretty good guess
> (locate-dominating-file tends to suffer from such performance problems
> in some cases, and vc-handled-backends is one user of this function,
> and dir-locals is another, so setting locate-dominating-stop-dir-regexp
> should really kill it off).
>    

I think it odd that it shaved time off rather than made things much 
worse.  One of the reasons for this variable is that when Windows tries 
to locate all the siblings of //machine, and in some cases 
//machine/share (where the user only has access to some shares), the 
process takes a long time. Perhaps the original value is incorrect?

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jason Rumney <jasonr <at> f2s.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Mon, 05 Apr 2010 20:46:21 -0400

>>>> (setq locate-dominating-stop-dir-regexp "")
>>> That maybe shaves off half a second.
>> Hmm... odd.  That seemed like a pretty good guess
>> (locate-dominating-file tends to suffer from such performance problems
>> in some cases, and vc-handled-backends is one user of this function,
>> and dir-locals is another, so setting locate-dominating-stop-dir-regexp
>> should really kill it off).
> I think it odd that it shaved time off rather than made things much worse.

The "" regexp always matches, so it will cause locate-dominating-file to
stop at the first occasion.


        Stefan

Message #35 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Tue, 6 Apr 2010 09:12:40 +0200

> That's strange: I thought they would slash much more.
>
> How about insert-file-contents and insert-file-contents-literally --
> can you time those?

I changed the measure function to this:

(defun measure ()
  (dotimes (i 10)
    (let ((time1 (float-time))
	  time2)
      (with-temp-buffer
	(insert-file-contents
"//corpnet/files/Archive/Archive75/docman/core/docman
5.11.0/docman/database/docman/refobj.apy"))
      (setq time2 (float-time))
      (message "Time elapsed for insert-file-contents: %s" (- time2 time1)))))

The results are very interesting:

emacs -Q
Time elapsed for insert-file-contents: 3.5160000324249268
Time elapsed for insert-file-contents: 0.6719999313354492
Time elapsed for insert-file-contents: 0.6410000324249268
Time elapsed for insert-file-contents: 0.6559998989105225
Time elapsed for insert-file-contents: 0.6089999675750732
Time elapsed for insert-file-contents: 0.6410000324249268
Time elapsed for insert-file-contents: 0.687000036239624
Time elapsed for insert-file-contents: 0.6719999313354492
Time elapsed for insert-file-contents: 0.5940001010894775
Time elapsed for insert-file-contents: 0.9689998626708984
(setq vc-handled-backends nil)
Time elapsed for insert-file-contents: 0.687000036239624
Time elapsed for insert-file-contents: 0.6100001335144043
Time elapsed for insert-file-contents: 0.6089999675750732 [2 times]
Time elapsed for insert-file-contents: 0.5940001010894775
Time elapsed for insert-file-contents: 2.984999895095825
Time elapsed for insert-file-contents: 0.7030000686645508
Time elapsed for insert-file-contents: 1.2339999675750732
Time elapsed for insert-file-contents: 0.625
Time elapsed for insert-file-contents: 0.6099998950958252
(setq locate-dominating-stop-dir-regexp "")
Time elapsed for insert-file-contents: 0.6089999675750732
Time elapsed for insert-file-contents: 0.625
Time elapsed for insert-file-contents: 0.6410000324249268
Time elapsed for insert-file-contents: 0.5930001735687256
Time elapsed for insert-file-contents: 0.5939998626708984
Time elapsed for insert-file-contents: 1.0160000324249268
Time elapsed for insert-file-contents: 0.6719999313354492
Time elapsed for insert-file-contents: 0.625
Time elapsed for insert-file-contents: 0.6089999675750732
Time elapsed for insert-file-contents: 0.6090002059936523

(This is for the larger of the two files)

Suddenly we get relatively good results.

> Another idea is to use elp.el to profile the various functions called
> by find-file.  At least for the Lisp level, we will see where's the
> bottleneck, and that might give some ideas.

This is my first attempt at using elp.el so I might not know what I am
doing :) I sucked out all function calls in find-file-noselect and got
this:

find-file-noselect                30          122.34599999  4.0782
find-file-noselect-1              30          85.545000000  2.8515000000
file-exists-p                     780         35.546999999  0.0455730769
file-truename                     63          30.012999999  0.4763968253
find-buffer-visiting              30          16.72         0.5573333333
file-attributes                   60          3.9890000000  0.0664833333
file-directory-p                  31          2.7210000000  0.0877741935
mapcar                            31          2.1270000000  0.0686129032
string-match                      8867        0.125         1.40...e-005
message                           35          0.031         0.0008857142
expand-file-name                  842         0.016         1.90...e-005
...

Digging further, instrumenting all functions in find-file-noselect-1
as well (the ones instrumented earlier is still instrumented):

find-file-noselect                30          119.71899999  3.9906333333
find-file-noselect-1              30          84.484000000  2.8161333333
insert-file-contents              30          42.253        1.4084333333
after-find-file                   30          42.230999999  1.4076999999
file-exists-p                     780         34.638999999  0.0444089743
file-truename                     60          29.048999999  0.4841499999
funcall                           40          21.326999999  0.533175
find-buffer-visiting              30          16.000999999  0.5333666666
file-attributes                   60          4.0619999999  0.0677
file-directory-p                  30          2.124         0.0708
mapcar                            25          2.045         0.0818
file-readable-p                   48          0.5800000000  0.0120833333
string-match                      8798        0.08          9.09...e-006
message                           33          0.064         0.0019393939
file-name-directory               890         0.048         5.39...e-005
expand-file-name                  841         0.0310000000  3.68...e-005
abbreviate-file-name              172         0.015         8.72...e-005
...

Does any figure above stand out to you?

/Mathias

Message #38 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Tue, 06 Apr 2010 10:15:48 +0200

> after-find-file                   30          42.230999999  1.4076999999

Does it sit-for in this?

martin

Message #41 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Tue, 06 Apr 2010 21:16:42 +0300

> From: Mathias Dahl <mathias.dahl <at> gmail.com>
> Date: Tue, 6 Apr 2010 09:12:40 +0200
> Cc: 5833 <at> debbugs.gnu.org
> 
> The results are very interesting:

If by ``interesting'' you mean the few large readings after the
initial one, I'd suspect some heavy network traffic at that moment
that slows down file access.  Do you have any other explanations?

> Suddenly we get relatively good results.

It means most of the time is not spent in actually reading the file,
but in something else.

> find-file-noselect                30          119.71899999  3.9906333333
> find-file-noselect-1              30          84.484000000  2.8161333333
> insert-file-contents              30          42.253        1.4084333333
> after-find-file                   30          42.230999999  1.4076999999
> file-exists-p                     780         34.638999999  0.0444089743
> file-truename                     60          29.048999999  0.4841499999

Perhaps look at why we spend about 1 sec (3.99 - 2.81) inside
find-file-noselect, and also why are we calling file-exists-p so many
times.

Message #44 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mathias.dahl <at> gmail.com, 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Wed, 07 Apr 2010 05:53:33 +0300

> Date: Tue, 06 Apr 2010 21:16:42 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 5833 <at> debbugs.gnu.org
> 
> > find-file-noselect                30          119.71899999  3.9906333333
> > find-file-noselect-1              30          84.484000000  2.8161333333
> > insert-file-contents              30          42.253        1.4084333333
> > after-find-file                   30          42.230999999  1.4076999999
> > file-exists-p                     780         34.638999999  0.0444089743
> > file-truename                     60          29.048999999  0.4841499999
> 
> Perhaps look at why we spend about 1 sec (3.99 - 2.81) inside
> find-file-noselect, and also why are we calling file-exists-p so many
> times.

Also, how is this comparable with the 7 seconds you reported
originally?  This says it only takes 4 to visit a file, not 7.

Message #47 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Wed, 7 Apr 2010 23:00:57 +0200

> Also, how is this comparable with the 7 seconds you reported
> originally?  This says it only takes 4 to visit a file, not 7.

I got 7 seconds in vanilla emacs -Q (no settings changed), IIRC. I
will test some more when I get the time.

/Mathias

Message #52 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Thu, 8 Aug 2019 05:30:00 +0200

Mathias Dahl <mathias.dahl <at> gmail.com> writes:

>> Also, how is this comparable with the 7 seconds you reported
>> originally?  This says it only takes 4 to visit a file, not 7.
>
> I got 7 seconds in vanilla emacs -Q (no settings changed), IIRC. I
> will test some more when I get the time.

Hi Mathias,

I'm writing this in reply to a 9 year old bug report of yours against
Emacs.  I've included your original bug report below for reference, and
you can read the full discussion at: https://debbugs.gnu.org/5833

Did you ever have a chance to look into this more in the intervening
years?  Can you still reproduce this issue on the latest version of
Emacs (26.2)?

Thanks in advance.

Best regards,
Stefan Kangas


Mathias Dahl <mathias.dahl <at> gmail.com> writes:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug.  If you can, give
> a recipe starting from `emacs -Q':
>
> I did this:
>
> emacs -Q
> C-x C-f //some_server/some_share/ RET
> Then, on some file in Dired, opened a file with f or RET.
>
> This operation is much slower than the same operation done using
> Notepad. For a file about 80 KB in size it takes about one second in
> Notepad and 5-6 seconds in Emacs.
>
> I have tried some tips found in old threads about this, like turning off
> some vc-parameter and some parameter controlling whether extra
> properties should be fetched (or something like that) for shares. No
> effect though. Opening local files is blazingly fast.
>
> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>     `bt full' and `xbacktrace'.
> For information about debugging Emacs, please read the file
> d:/pgm/emacs/etc/DEBUG.
>
>
> In GNU Emacs 23.1.94.1 (i386-mingw-nt5.1.2600)
>  of 2010-03-23 on G41R2F1
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --no-opt --cflags
> -Ic:/imagesupport/include'
>
> 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: SVE
>   value of $XMODIFIERS: nil
>   locale-coding-system: cp1252
>   default enable-multibyte-characters: t
>
> Major mode: Dired by name
>
> Minor modes in effect:
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   tool-bar-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>
> Recent input:
> C-x C-f C-y <return> <down> <down> <down> <return>
> <down-mouse-1> <mouse-1> M-: C-y <return> q M-: C-y
> <home> <right> <right> <right> <right> q <end> <return>
> C-x k <return> <up> <up> <return> <f5> <down> <up>
> <down> C-x k <return> M-x f i n d SPC f i l <tab> SPC
> l i <tab> <return> 5 1 0 0 <tab> <return> C-x k <return>
> <help-echo> <down> <down> <down> <down> <down> <down>
> <down> <down> <down> <down> <down> <down> <down> <down>
> <down> <down> C C-a C-k c Ö - <backspace> <backspace>
> : / m u u . t x t <return> C-x C-f <up> <return> <f5>
> <down> <up> C-x k <return> C-h c f f C-x k <return>
> <lwindow> <help-echo> <help-echo> <help-echo> <help-echo>
> <help-echo> <help-echo> <menu-bar> <help-menu> <se
> nd-emacs-bug-report>
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Entering debugger...
> Back to top level.
> nil
> Copy: 1 of 1
> Copy: 1 file
> f runs the command dired-find-file
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort mail-extr message ecomplete rfc822 mml mml-sec
> password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
> rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
> time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
> hex-util hashcash mail-utils emacsbug dired-aux help-mode easymenu view
> debug dired regexp-opt tooltip ediff-hook vc-hooks lisp-float-type
> mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset
> image fringe lisp-mode register page menu-bar rfn-eshadow timer select
> scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
> frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
> tai-viet lao korean japanese hebrew greek romanian slovak czech european
> ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
> simple abbrev loaddefs button minibuffer faces cus-face files
> text-properties overlay md5 base64 format env code-pages mule custom
> widget hashtable-print-readable backquote make-network-process multi-tty
> emacs)

Message #55 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 5833 <at> debbugs.gnu.org, mathias.dahl <at> gmail.com
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Thu, 08 Aug 2019 16:21:57 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 8 Aug 2019 05:30:00 +0200
> Cc: 5833 <at> debbugs.gnu.org
> 
> Did you ever have a chance to look into this more in the intervening
> years?  Can you still reproduce this issue on the latest version of
> Emacs (26.2)?

Meanwhile we have learned that one other possible culprit is the Net
Logon service, see etc/PROBLEMS for the details and the workaround.

Message #58 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5833 <at> debbugs.gnu.org, Mathias Dahl <mathias.dahl <at> gmail.com>
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Fri, 23 Aug 2019 19:36:53 +0200

tags 5833 + moreinfo
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: Stefan Kangas <stefan <at> marxist.se>
> > Date: Thu, 8 Aug 2019 05:30:00 +0200
> > Cc: 5833 <at> debbugs.gnu.org
> >
> > Did you ever have a chance to look into this more in the intervening
> > years?  Can you still reproduce this issue on the latest version of
> > Emacs (26.2)?
>
> Meanwhile we have learned that one other possible culprit is the Net
> Logon service, see etc/PROBLEMS for the details and the workaround.

Unless the original poster thinks otherwise, this indeed sounds like a
possible culprit.  Is there anything that Emacs can do better if that
is indeed the case, or is that just a limitation of Windows and its
Net Logon service?

Thanks,
Stefan Kangas

Message #63 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 5833 <at> debbugs.gnu.org, mathias.dahl <at> gmail.com
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Fri, 23 Aug 2019 22:27:11 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Fri, 23 Aug 2019 19:36:53 +0200
> Cc: Mathias Dahl <mathias.dahl <at> gmail.com>, 5833 <at> debbugs.gnu.org
> 
> > Meanwhile we have learned that one other possible culprit is the Net
> > Logon service, see etc/PROBLEMS for the details and the workaround.
> 
> Unless the original poster thinks otherwise, this indeed sounds like a
> possible culprit.  Is there anything that Emacs can do better if that
> is indeed the case, or is that just a limitation of Windows and its
> Net Logon service?

Maybe we could do more, but I have no idea how.  I don't know enough
aboutr the reason for the slowness of that particular operation.

Message #66 received at 5833 <at> debbugs.gnu.org (full text, mbox):

From: Mathias Dahl <mathias.dahl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Kangas <stefan <at> marxist.se>, 5833 <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Sat, 24 Aug 2019 10:46:30 +0200

[Message part 1 (text/plain, inline)]

Hi all,

Sorry for the late reply. I did a test now, on Emacs 24.3 as well as 26.1,
and I don't see the problem anymore. Many moons have passed and I am now on
Windows 10 and who knows what changes our IT dept. have done in our network
configuration.

I think this can be closed (if others does not experience this still)

Thanks for the attention though.

/Mathias


On Fri, Aug 23, 2019 at 9:27 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Stefan Kangas <stefan <at> marxist.se>
> > Date: Fri, 23 Aug 2019 19:36:53 +0200
> > Cc: Mathias Dahl <mathias.dahl <at> gmail.com>, 5833 <at> debbugs.gnu.org
> >
> > > Meanwhile we have learned that one other possible culprit is the Net
> > > Logon service, see etc/PROBLEMS for the details and the workaround.
> >
> > Unless the original poster thinks otherwise, this indeed sounds like a
> > possible culprit.  Is there anything that Emacs can do better if that
> > is indeed the case, or is that just a limitation of Windows and its
> > Net Logon service?
>
> Maybe we could do more, but I have no idea how.  I don't know enough
> aboutr the reason for the slowness of that particular operation.
>

[Message part 2 (text/html, inline)]

Message #71 received at 5833-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mathias Dahl <mathias.dahl <at> gmail.com>
Cc: stefan <at> marxist.se, 5833-done <at> debbugs.gnu.org
Subject: Re: bug#5833: 23.1.94; Opening files on network shares on w32 is slow
Date: Sat, 24 Aug 2019 13:13:16 +0300

> From: Mathias Dahl <mathias.dahl <at> gmail.com>
> Date: Sat, 24 Aug 2019 10:46:30 +0200
> Cc: Stefan Kangas <stefan <at> marxist.se>, 5833 <at> debbugs.gnu.org
> 
> Sorry for the late reply. I did a test now, on Emacs 24.3 as well as 26.1, and I don't see the problem anymore.
> Many moons have passed and I am now on Windows 10 and who knows what changes our IT dept. have
> done in our network configuration.
> 
> I think this can be closed (if others does not experience this still)
> 
> Thanks for the attention though.

Thanks for getting back to us.  I'm closing this bug report.

Previous Next

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