GVim runs very slowly when editing files on a windows share

On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. I开发者_开发技巧s that right?

There are a few factors which may affect this.

First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.

set directory^=$HOME/tmp

This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.

Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.

Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.

let g:loaded_matchparen = 1

If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.

Finally, if none of those help you can always copy the file locally and edit it.

Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"

It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".

Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".

Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away. Then CreateFile on "\server\TestTool\foo" which works right away. Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.

WHY is it trying bad names for the server and the root directory??? What madness is this?

I fixed this issue after setting HOME path by force in advanced system settings. (Your current HOME path would be a network directory.)

Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables

Press "New..."

Variable name: HOME

Variable value: c:\Home\ **<-- Type your home directory**

A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc

autocmd BufReadPre //* :NoMatchParen

You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.

Having a similar issue as David Anderson, but no solution yet.

When loading \\ServerName\A$\B\C\File.txt Vim will do:

• Open \ServerName\A$\B\C\File.txt

Then it does many loops like:

• CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
• QueryDirectory \ServerName\A$\B
• QueryDirectory \ServerName\A$
• QueryDirectory \ServerName\A$\B\C
• QueryDirectory \ServerName\A$\B

To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.

Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.

I've no plugins installed as far as I know and followed other tips to speed up network shares loading.

Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.

I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.

Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:

With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:

set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)

For local files that's ok, but for network files this is way too slow.

Now my fix:

set titlestring=

Same effect (filename first), but now gvim runs very fast for remote files as well!

BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.

It all had no effect for me. But the funny titlestring...