Re: File operations really slow in emacs

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 11/02/2012 5:11 AM, Corinna Vinschen wrote:
> On Feb 10 20:18, Ryan Johnson wrote:
> > Hi all,
> >
> > For some reason file operations have become very slow inside emacs
> > starting yesterday. It's especially painful when saving a file
> > that's managed by mercurial (more than 20 seconds!), but I've seen
> > it on the command line as well (x-server takes a similar amount of
> > time to start, for example). I'm running the latest everything and
> > I've run rebaseall. I verified that Windows Defender did not
> > silently re-enable itself since I last disabled it (you can't
> > actually uninstall it) and no other BLODA are present on my machine.
> > The problem persists across reboots.
> >
> > I have vague memories that this has turned up in the past (maybe
> > 12-15 months ago?) but Google isn't turning up anything. Attaching
> > strace to emacs during the save makes it take a full 35 seconds and
> > reports the following:
> >
> > $ cat emacs.strace | awk '{if ($1>  1000000) { print }}' | grep -v
> > timer_thread
> > 26910790 26912157 [main] emacs-X11 5188 child_copy: dll bss - hp
> > 0x264 low 0x611FC000, high 0x61230770, res 1
> > 1128419 2125655 [main] python2.6 5188 read: read(5, 0x8009DB60,
> > 65536) blocking
> > 25850184 32830582 [main] python2.6 5188 stat_worker: 0 =
> > (\??\C:\cygwin\cygdrive,0x28BB68)
>    ^^^^^^^^^^^^^^^^^^^^^^^
>    This looks suspicious.  I assume you're suffering from SMB network
>    scanning.
Turns out you were right after all. I have Z: mapped to a SMB share 
that's only visible when I'm connected to the VPN it lives on; I hadn't 
used it in a few months and it didn't show up in Explorer, but it was on 
the list of drives returned by GetLogicalDriveStrings(). Connecting the 
drive makes everything run at normal speed, and disconnecting it makes 
the problem return a short time later.

Oddly, I've never observed the effect when running from an elevated 
prompt -- I can reliably fire off 'stat /cygdrive' in a normal prompt, 
open an elevated mintty, run the same command there, get the results, 
and close the window, all well before the first stat completes.

So, three questions:
- why is the elevated prompt unaffected?
- why does hg feel a need to access /cygdrive?
- is there a workaround? Neither "always run elevated" nor "always keep 
all network drives mounted" seems like a reasonable requirement, but 
that elevated prompt is looking mighty nice right about now. I suppose I 
could also drop the for loop from fhandler_cygdrive::fstat and set 
st_nlink to either 3 or 2+ndrives (on the assumption that the change 
won't affect anyone's decision to unlink /cygdrive and that the number 
is otherwise meaningless).

Thoughts?
Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple