Vim slow over UNC paths - vim

Question

I am experiencing some very painful lag when accessing directories/files over UNC paths using gVim 7.3 on Windows Vista.
It is slow reading/writing files, as well as tab completiong of directory/file names when opening new buffers. I don't notice this lag when using WordPad though.
Things I've tried:
Cream (apparently they had a fix for directory naming schemes)
Mapping the network drive to z: or something else
Various settings
set ffs=dos
set complete=.,w,b,u,t
set noshellslash
I've tried cygwin, but the same noticeable lag appears there as well. I already have all swap/backup files turned off. Any help greatly appreciated... I've dumped my vimrc for reference
if v:progname =~? "evim"
finish
endif
set nocompatible
:runtime! ftplugin/man.vim
set backspace=indent,eol,start
colorscheme torte " murphy
syn on
set ffs=unix,dos
" portable friendly
set nobackup
set nowritebackup
set noswapfile
set viminfo=
" gui options (http://steveno.wordpress.com/2007/10/08/vim-for-windows/)
set guioptions-=T " No toolbar
set gfn=Consolas:h9:cANSI
set history=50
set ruler
set showcmd
set incsearch
set number
set tabstop=4
set softtabstop=4
set shiftwidth=4
set wrap
set wildmode=longest,list,full " Complete longest string, list alternatives
" then completed next full match, cycling back
function! ToggleHLSearch()
if &hls
set nohls
else
set hls
endif
endfunction
function! InsertTabWrapper()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return "\<tab>"
else
return "\<c-p>"
endif
endfunction
inoremap <tab> <c-r>=InsertTabWrapper()<CR>
nmap <silent> <C-n> <Esc>:call ToggleHLSearch()<CR>
nmap ,s :source ~/.vimrc<Return>
" change current directory to that of open buffer
nmap ,c :cd %:p:h<Return>
nmap <c-h> <c-w>h<c-w><bar>
nmap <c-l> <c-w>l<c-w><bar>
map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_
map Q gq
" Commenting blocks of text
" ,< <!-- --> html style comments
map ,< :s/^\(.*\)$/<!-- \1 -->/<CR><Esc>:nohlsearch<CR>
" ,/ // comments
map ,/ :s/^/\/\//<CR>
" ,# # comments
map ,# :s/^/#/<CR>
" uncommenting all of the above
"map ,- :s/^\(\/\/|<!-- |#\)\(.*\)\(-->\)*/\1/<CR>
if &t_Co > 2 || has("gui_running")
syntax on
set hlsearch
endif
if has("autocmd")
"&& !exists("autocommands_loaded")
let autocommands_loaded = 1
filetype plugin indent on
augroup vimrcEx
au!
" Remove ALL autocommands for the current group.
autocmd!
autocmd FileType text setlocal textwidth=78
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |
\ endif
au BufRead *.html set filetype=html4
augroup END
" allow editing Word Docs sanely
autocmd BufReadPre *.doc set ro
autocmd BufReadPre *.doc set hlsearch!
autocmd BufReadPost *.doc %!antiword "%"
" uncomment the following to remember the view of the file edited between
" sessions
" au BufWinLeave * mkview
" au BufWinEnter * silent loadview
" run file with PHP CLI (CTRL-M)
autocmd FileType php noremap <C-M> :w!<CR>:!/usr/bin/php %<CR>
" parser check (CTRL-L)
autocmd FileType php noremap <C-L> :!/usr/bin/php -l %<CR>
" highlight current line only for current buffer
"autocmd BufLeave * setlocal nocursorline
"autocmd BufEnter * setlocal cursorline
au BufRead,BufNewFile *.tea set filetype=tea
"au! Syntax newlang source $VIM/newlanguage.vim
else
set autoindent
endif

Answer 1

the same thing was driving me insane, but there is a fix I just found.
I really do not know why yet, but the problem goes away when you disable plugin/matchparen.vim plugin (changing vim extension would do the trick).
I will definitely look into it as I use parentheses matching a lot.

Answer 2

See
:he swap-file
You can disable swapfiles with :se noswapfile (caution!) or use the `directory` setting to keep the swapfile on a local disk.
Starting vim with the -n option also disables swapfiles; you might want to combine that with -R for readonly mode

Answer 3

Another solution I found is that mounting a UNC path as a local drive letter and let Vim use the drive-letter based paths only.
e.g., \\some-server\path\to\workdir => Z:\path\to\workdir
This eliminates the lag completely unless you have connection problems.