gvim is very slow for movement keys when editing remote files

236 views
Skip to first unread message

asgeo1

unread,
Apr 3, 2009, 9:17:42 PM4/3/09
to vim_use
Hello,

I often use gvim at home editing files from work over the VPN. I am
accessing the files through drives I have mapped in Windows, rather
than using UNC paths directly.

Anyway, editing these files on-site at work is cool and performs fine
and when I'm at home I can edit local files ok too with no performance
issues.

BUT for some reason - editing remote files in gvim is extremely slow!
I'm not talking about the startup time here. I'm talking about once
the file has actually loaded and I'm now working in the editor.

The scrolling speed when using the movement keys (hjkl) is appalling.
In fact, any movement operation is painful. Using the movement keys to
move between split windows takes forever (a few seconds). Moving the
cursor down a single line takes at least a couple of seconds.


The only exception is that the mouse scroll wheel is the only movement
operation not effected by this issue - I can scroll without any issue
using the mouse scroll wheel. (Although the whole point of using vim
for me is that I don't have to touch the mouse :-/


So - does anyone know what is going on? I have suffered this problem
for years and always hoped it would be fixed in future vim releases.

I just don't get why it needs to be so slow for editing remote files.
The buffer is in memory so I don't get why it would be slow.

Any advice would be appreciated.

Regards,
-asgeo1

Tony Mechelynck

unread,
Apr 3, 2009, 10:25:07 PM4/3/09
to vim...@googlegroups.com

Probably gvim is trying to write its swapfile (the disk file where it
saves your changes in order to be able to restart with as little loss as
possible in case of a crash) to the same drive as the file being edited,
which is OK for local files, but can raise performance issues for remote
files.

Solution I (recommended)
----------
Copy the remote file to a local directory, edit it there, and copy it
back when you're done for the day. This is the easiest to figure out how
to do correctly. Also, intermediate saves (if you use ":w") will proceed
OK even if your line to the remote host goes down. All this rigmarole is
unnecessary for readonly files (e.g. when using ":view" or ":sview")
since there are no changes then, hence no swapfile, unless of course you
change your mind and decide to make changes to the file after all.

Solution II
-----------
First,

:set nobackup writebackup

Then, if it still isn't good enough, try to figure out from the help how
Vim figures out where to write its backup and swap files, and make sure
that at least the swapfile is either local or nonexistent.


Best regards,
Tony.
--
In case of atomic attack, the federal ruling against prayer in schools
will be temporarily canceled.

Tim Chase

unread,
Apr 3, 2009, 10:25:26 PM4/3/09
to vim...@googlegroups.com
> I just don't get why it needs to be so slow for editing remote files.
> The buffer is in memory so I don't get why it would be slow.

The first thing that occurs to me is the swapfile settings. If
it's trying to write the swapfile to the same remote network
location, you'll get horrid lag. Try

:set directory-=.

or

:let &directory=$TEMP

to instruct vim to write the swapfile(s) elsewhere.
Alternatively, you can shut the swapfile off completely:

:set noswapfile

or reduce the frequency with which it writes to the swapfile:

:set updatecount=10000


One last alternative occurs to me: check the output of

:map

to see if you have any mappings for h/j/k/l and check

:autocmd CursorHold
:autocmd CursorHoldI
:autocmd CursorMoved
:autocmd CursorMovedI

to see if any event is firing that might drag you down.

-tim


asgeo1

unread,
Apr 4, 2009, 12:26:45 AM4/4/09
to vim_use
Hi guys,

Thanks for some quick replies.

The suggestions on the autocmds were correct. I have worked out it is
the matchparen.vim plugin that is causing the problem. This plugin
ships with the stock Vim 7.2.

It sets various auto commands for highlighting the matching
parentheses. Disabling this plugin fixes my problem.

I haven't worked out *why* this plugin is causing my problem - in
theory it should be operating on the buffer in memory - not talking
back to the remote server. Strange.

For now I will just toggle the plugin on/off as I need to:


function! s:ToggleMatchParen()
if exists("g:loaded_matchparen")
:NoMatchParen
:echo 'MatchParen plugin turned off'
else
:DoMatchParen
:echo 'MatchParen plugin turned on'
endif
endfunction


Regards,
-adam
Reply all
Reply to author
Forward
0 new messages