* bug#3252: 23.0.93; extremely slow to open file on windows network drive @ 2009-05-10 22:13 ` Chris Withers 2009-05-11 3:06 ` Eli Zaretskii 2009-05-20 13:00 ` bug#3252: marked as done (23.0.93; extremely slow to open file on windows network drive) Emacs bug Tracking System 0 siblings, 2 replies; 23+ messages in thread From: Chris Withers @ 2009-05-10 22:13 UTC (permalink / raw) To: emacs-pretest-bug 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-10 22:13 ` bug#3252: 23.0.93; extremely slow to open file on windows network drive Chris Withers @ 2009-05-11 3:06 ` Eli Zaretskii 2009-05-11 8:36 ` Chris Withers 2009-05-20 13:00 ` bug#3252: marked as done (23.0.93; extremely slow to open file on windows network drive) Emacs bug Tracking System 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-11 3:06 UTC (permalink / raw) To: Chris Withers, 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 3:06 ` Eli Zaretskii @ 2009-05-11 8:36 ` Chris Withers 2009-05-11 18:08 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Chris Withers @ 2009-05-11 8:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 8:36 ` Chris Withers @ 2009-05-11 18:08 ` Eli Zaretskii 2009-05-11 18:11 ` Chris Withers 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-11 18:08 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 18:08 ` Eli Zaretskii @ 2009-05-11 18:11 ` Chris Withers 2009-05-11 18:25 ` Eli Zaretskii 2009-05-11 21:15 ` Stefan Monnier 0 siblings, 2 replies; 23+ messages in thread From: Chris Withers @ 2009-05-11 18:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 18:11 ` Chris Withers @ 2009-05-11 18:25 ` Eli Zaretskii 2009-05-11 18:28 ` Chris Withers 2009-05-11 21:15 ` Stefan Monnier 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-11 18:25 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 18:25 ` Eli Zaretskii @ 2009-05-11 18:28 ` Chris Withers 2009-05-11 18:41 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Chris Withers @ 2009-05-11 18:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 18:28 ` Chris Withers @ 2009-05-11 18:41 ` Eli Zaretskii 0 siblings, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2009-05-11 18:41 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 18:11 ` Chris Withers 2009-05-11 18:25 ` Eli Zaretskii @ 2009-05-11 21:15 ` Stefan Monnier 2009-05-11 22:06 ` Chris Withers 1 sibling, 1 reply; 23+ messages in thread From: Stefan Monnier @ 2009-05-11 21:15 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 >> 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 21:15 ` Stefan Monnier @ 2009-05-11 22:06 ` Chris Withers 2009-05-12 4:49 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Chris Withers @ 2009-05-11 22:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-11 22:06 ` Chris Withers @ 2009-05-12 4:49 ` Eli Zaretskii 2009-05-16 16:23 ` Chris Withers 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-12 4:49 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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"? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-12 4:49 ` Eli Zaretskii @ 2009-05-16 16:23 ` Chris Withers 2009-05-16 17:48 ` Eli Zaretskii 0 siblings, 1 reply; 23+ messages in thread From: Chris Withers @ 2009-05-16 16:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-16 16:23 ` Chris Withers @ 2009-05-16 17:48 ` Eli Zaretskii 2009-05-18 10:16 ` Chris Withers 0 siblings, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-16 17:48 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-16 17:48 ` Eli Zaretskii @ 2009-05-18 10:16 ` Chris Withers 2009-05-18 10:37 ` Lennart Borgman 2009-05-18 18:19 ` Eli Zaretskii 0 siblings, 2 replies; 23+ messages in thread From: Chris Withers @ 2009-05-18 10:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 10:16 ` Chris Withers @ 2009-05-18 10:37 ` Lennart Borgman 2009-05-18 12:41 ` Jason Rumney 2009-05-18 18:19 ` Eli Zaretskii 1 sibling, 1 reply; 23+ messages in thread From: Lennart Borgman @ 2009-05-18 10:37 UTC (permalink / raw) To: Chris Withers, 3252 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?) ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 10:37 ` Lennart Borgman @ 2009-05-18 12:41 ` Jason Rumney 2009-05-18 12:49 ` Lennart Borgman 0 siblings, 1 reply; 23+ messages in thread From: Jason Rumney @ 2009-05-18 12:41 UTC (permalink / raw) To: Lennart Borgman, 3252; +Cc: Chris Withers 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 12:41 ` Jason Rumney @ 2009-05-18 12:49 ` Lennart Borgman 0 siblings, 0 replies; 23+ messages in thread From: Lennart Borgman @ 2009-05-18 12:49 UTC (permalink / raw) To: Jason Rumney; +Cc: 3252, Chris Withers 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 10:16 ` Chris Withers 2009-05-18 10:37 ` Lennart Borgman @ 2009-05-18 18:19 ` Eli Zaretskii 2009-05-18 19:13 ` Chris Withers 1 sibling, 1 reply; 23+ messages in thread From: Eli Zaretskii @ 2009-05-18 18:19 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 18:19 ` Eli Zaretskii @ 2009-05-18 19:13 ` Chris Withers 2009-05-18 20:31 ` Eli Zaretskii 2009-05-19 2:12 ` Stefan Monnier 0 siblings, 2 replies; 23+ messages in thread From: Chris Withers @ 2009-05-18 19:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 19:13 ` Chris Withers @ 2009-05-18 20:31 ` Eli Zaretskii 2009-05-19 2:12 ` Stefan Monnier 1 sibling, 0 replies; 23+ messages in thread From: Eli Zaretskii @ 2009-05-18 20:31 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-18 19:13 ` Chris Withers 2009-05-18 20:31 ` Eli Zaretskii @ 2009-05-19 2:12 ` Stefan Monnier 2009-05-20 10:35 ` Chris Withers 1 sibling, 1 reply; 23+ messages in thread From: Stefan Monnier @ 2009-05-19 2:12 UTC (permalink / raw) To: Chris Withers; +Cc: 3252 > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: 23.0.93; extremely slow to open file on windows network drive 2009-05-19 2:12 ` Stefan Monnier @ 2009-05-20 10:35 ` Chris Withers 0 siblings, 0 replies; 23+ messages in thread From: Chris Withers @ 2009-05-20 10:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: 3252 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#3252: marked as done (23.0.93; extremely slow to open file on windows network drive) 2009-05-10 22:13 ` bug#3252: 23.0.93; extremely slow to open file on windows network drive Chris Withers 2009-05-11 3:06 ` Eli Zaretskii @ 2009-05-20 13:00 ` Emacs bug Tracking System 1 sibling, 0 replies; 23+ messages in thread From: Emacs bug Tracking System @ 2009-05-20 13:00 UTC (permalink / raw) To: Jason Rumney [-- 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-05-20 13:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <4A13FD0A.5070306@gnu.org> 2009-05-10 22:13 ` bug#3252: 23.0.93; extremely slow to open file on windows network drive Chris Withers 2009-05-11 3:06 ` Eli Zaretskii 2009-05-11 8:36 ` Chris Withers 2009-05-11 18:08 ` Eli Zaretskii 2009-05-11 18:11 ` Chris Withers 2009-05-11 18:25 ` Eli Zaretskii 2009-05-11 18:28 ` Chris Withers 2009-05-11 18:41 ` Eli Zaretskii 2009-05-11 21:15 ` Stefan Monnier 2009-05-11 22:06 ` Chris Withers 2009-05-12 4:49 ` Eli Zaretskii 2009-05-16 16:23 ` Chris Withers 2009-05-16 17:48 ` Eli Zaretskii 2009-05-18 10:16 ` Chris Withers 2009-05-18 10:37 ` Lennart Borgman 2009-05-18 12:41 ` Jason Rumney 2009-05-18 12:49 ` Lennart Borgman 2009-05-18 18:19 ` Eli Zaretskii 2009-05-18 19:13 ` Chris Withers 2009-05-18 20:31 ` Eli Zaretskii 2009-05-19 2:12 ` Stefan Monnier 2009-05-20 10:35 ` Chris Withers 2009-05-20 13:00 ` bug#3252: marked as done (23.0.93; extremely slow to open file on windows network drive) Emacs bug Tracking System
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).