This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: File operations really slow in emacs

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
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 =
   This looks suspicious.  I assume you're suffering from SMB network
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).


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]