OS == FreeBSD-12.1p2
Vim == 8.1.2372
I am encountering a problem with vim having an excessively slow startup time on just one system. The content of vim --startuptime vim_startuptime.log follows:
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.030 000.030: --- VIM STARTING ---
000.166 000.136: Allocated generic buffers
000.293 000.127: locale set
000.307 000.014: GUI prepared
000.309 000.002: clipboard setup
000.334 000.025: window checked
001.000 000.666: inits 1
001.064 000.064: parsing arguments
001.066 000.002: expanding arguments
001.136 000.070: shell init
001.795 000.659: Termcap init
001.846 000.051: inits 2
002.060 000.214: init highlight
003.900 001.183 001.183: sourcing /usr/local/share/vim/vim81/syntax/syncolor.vim
. . .
018.890 001.561: loading plugins
018.997 000.107: loading packages
019.028 000.031: loading after plugins
019.077 000.049: inits 3
019.197 000.120: reading viminfo
75047.076 75027.879: setup clipboard
75047.146 000.070: setting raw mode
75047.161 000.015: start termcap
75047.191 000.030: clearing screen
75047.457 000.266: opening buffers
75047.551 000.094: BufEnter autocommands
75047.555 000.004: editing files in windows
75047.741 000.186: VimEnter autocommands
75047.744 000.003: before starting main loop
75048.149 000.405: first screen update
75048.151 000.002: --- VIM STARTED ---
However, if I disable X then this is the result (vim -X --startuptime vim_startuptime-X.log):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.030 000.030: --- VIM STARTING ---
000.165 000.135: Allocated generic buffers
000.293 000.128: locale set
000.309 000.016: GUI prepared
000.310 000.001: clipboard setup
000.336 000.026: window checked
001.009 000.673: inits 1
001.074 000.065: parsing arguments
001.076 000.002: expanding arguments
001.146 000.070: shell init
001.801 000.655: Termcap init
001.853 000.052: inits 2
002.067 000.214: init highlight
003.936 001.214 001.214: sourcing /usr/local/share/vim/vim81/syntax/syncolor.vim
. . .
019.029 001.555: loading plugins
019.137 000.108: loading packages
019.168 000.031: loading after plugins
019.192 000.024: inits 3
019.307 000.115: reading viminfo
019.309 000.002: setup clipboard
019.363 000.054: setting raw mode
019.376 000.013: start termcap
019.402 000.026: clearing screen
019.811 000.409: opening buffers
019.856 000.045: BufEnter autocommands
019.859 000.003: editing files in windows
020.005 000.146: VimEnter autocommands
020.008 000.003: before starting main loop
020.390 000.382: first screen update
020.391 000.001: --- VIM STARTED ---
I connect to this system using ssh -X -t and generally use gvim to display the editing window on my desktop. When I do that on the problem host in addition to the long delay I get the message that the the child process could not open the GUI. I have previously run gvim on this host without issue.
Both hosts' /etc/ssh/sshd_config file are identical save for the Listen address. Yhe X11 entries in each are listed below:
grep -in x11 /etc/ssh/sshd_config
102:#X11Forwarding yes
103:#X11DisplayOffset 10
104:#X11UseLocalhost yes
147:# To allow ssh tunneling in jails set X11UseLocalhost to NO
148:X11UseLocalhost no
174:# X11Forwarding no
I have an identically configured host (hardware, OS, sshd_config) that I also connect to via ssh -X -t where this problem does not occur. I have tried removing and reinstalling vim on the problem host, which makes no difference.
Likewise I removed the .vim directory and .viminfo file from the user's home directory. This had no effect on startup time. This issue is not confined to a single userid in any case.
A debugging log (vim -V9vim_startup_debug.log) contains this:
. . .
Searching for "/usr/local/share/vim/vimfiles/after/plugin/**/*.vim"
Searching for "/root/.vim/after/plugin/**/*.vim"
not found in 'runtimepath': "plugin/**/*.vim"
Reading viminfo file "/root/.viminfo" info oldfiles
Opening the X display failed
Executing BufEnter Autocommands for "*"
autocommand sil call s:LocalBrowse(expand("<amatch>"))
. . .
I am open to suggestions as to how to resolve this problem. It is evident that X11 forwarding is somehow involved and that the clipboard setup is where the problem is happening, but I have no idea how to discover what the actual problem is.
Related
Edit a remote file with
vim scp://remote/file
Saving the file with :w blocks the editor till the file changes are saved to the remote.
I was trying to use :Dispatch :write to avoid being blocked but that does not work (using tmux or iterm strategy). :Dispatch is provided by the plugin vim-dispatch.
Relevant internet search results suggest:
Ssh to remote and work there (if you have a slow connection, check this question or consider ssh-alternative mosh)
eshion/vim-sync offers the possibility to autosync changes of a local file to the remote
Git hook auto-push: after each commit push changes to the remote
satiani/async-scp-vim (see for details blog) launch SCP calls whenever the BufWritePost event is triggered
Ssh tunnel faster write due to open ssh connection (see also Speeding up Vim's Netrw plugin over ssh/scp and autossh).
sshfs/osxfuse-sshfs set directory=~/.vim/swaps//; set backupdir=~/.vim/backups
Neovim no release yet and nightly build does not do it out of the box. Any answer here appreciated. It has been reported as an issue #1464
Backchannel Vi
The solutions are helpful but require setup of vcs, config files, etc.
I'd prefer
to work locally
no configuration for each file (configuring the editor once and for all is ok)
Not every write should be a commit.
Keeping an ssh tunnel open didn't improve it either.
Update
I'd like to know whether there is a solution to run the save process asynchronously. The save process means here, as netrw is showing in the commandline, a scp call to copy the temp file to the remote which can take some time. I'd like to return to my editing in the meanwhile and don't be blocked. I hope this makes my question clearer.
Alternatives to tpope/dispatch are:
Shougo/vimproc, idbrii/AsyncCommand, which I haven't tried yet.
It was an old question, yet I encountered the same problem of how to work with remote files efficiently.
My solution is to use unison to sync files on the fly. A command is defined to call the sync function within vim.
function! s:Sync()
call system("unison -batch /home/user ssh://user#server//home/user")
endfunction
command! Sync :call <SID>Sync()
The speed of sync files using unison is so fast that I don't have much motivation to make it run asynchronously.
SSHFS: My Problem with sshfs was the vim plugin lightline.vim using fugitive.vim function.
The statusline is updated quite often when you scroll (line number changes) and therefore the fugitive function to show the current branch was evaluated all the time.
This slowed the scrolling significantly down. Removing fugitive status from statusline alleviated the slow down.
There is another plugin https://github.com/seletskiy/vim-refugi which reports that
git through sshfs is slow as hell.
I also installed this plugin for fugitive and applied their tip
Because this script uses ssh multiplexing, it is good to configure your
ssh to automatically open master connections.
E.g. you need this in your ~/.ssh/config:
host *
controlmaster auto
controlpath ~/.ssh/connections/%r_%h_%p
Plugin AsyncRun for vim8/neovim
describes on following wiki page how to get netrw using this plugin when saving to remote:
https://github.com/skywind3000/asyncrun.vim/wiki/Get-netrw-using-asyncrun-to-save-remote-files
Copy of the patch:
Following diff to $VIMRUNTIME/autoload/netrw.vim (version 156) saves asynchronously with AsyncRun when you put into your vimrc let g:netrw_write_AsyncRun = 1:
❯ git diff netrw-156.vim netrw.vim
diff --git a/netrw-156.vim b/netrw.vim
index 76485c2..183fc96 100644
--- a/netrw-156.vim
+++ b/netrw.vim
## -510,6 +510,7 ## call s:NetrwInit("g:NetrwTopLvlMenu","Netrw.")
call s:NetrwInit("g:netrw_win95ftp",1)
call s:NetrwInit("g:netrw_winsize",50)
call s:NetrwInit("g:netrw_wiw",1)
+call s:NetrwInit("g:netrw_write_AsyncRun",0)
if g:netrw_winsize > 100|let g:netrw_winsize= 100|endif
" ---------------------------------------------------------------------
" Default values for netrw's script variables: {{{2
## -2377,6 +2378,14 ## fun! netrw#NetWrite(...) range
" call Decho("(netrw) Processing your write request...",'~'.expand("<slnum>"))
endif
+ " NetWrite: Perform AsyncRun Write {{{3
+ " ============================
+ if exists("g:netrw_write_AsyncRun") && g:netrw_write_AsyncRun == 1
+ let bang_cmd = 'AsyncRun -post=call\ delete('.s:ShellEscape(tmpfile,1).')\ |\ echo\ "(netrw)\ Your\ write\ request\ has\ finished." '
+ else
+ let bang_cmd ="!"
+ endif
+
".........................................
" NetWrite: (rcp) NetWrite Method #1 {{{3
if b:netrw_method == 1
## -2515,7 +2524,7 ## fun! netrw#NetWrite(...) range
else
let useport= ""
endif
- call s:NetrwExe(s:netrw_silentxfer."!".g:netrw_scp_cmd.useport." ".s:ShellEscape(tmpfile,1)." ".s:ShellEscape(g:netrw_machine.":".b:netrw_fname,1))
+ call s:NetrwExe(s:netrw_silentxfer.bang_cmd.g:netrw_scp_cmd.useport." ".s:ShellEscape(tmpfile,1)." ".s:ShellEscape(g:netrw_machine.":".b:netrw_fname,1))
let b:netrw_lastfile = choice
".........................................
## -2612,9 +2621,11 ## fun! netrw#NetWrite(...) range
" NetWrite: Cleanup: {{{3
" call Decho("cleanup",'~'.expand("<slnum>"))
- if s:FileReadable(tmpfile)
-" call Decho("tmpfile<".tmpfile."> readable, will now delete it",'~'.expand("<slnum>"))
- call s:NetrwDelete(tmpfile)
+ if !exists("g:netrw_write_AsyncRun") || g:netrw_write_AsyncRun == 0
+ if s:FileReadable(tmpfile)
+" call Decho("tmpfile<".tmpfile."> readable, will now delete it",'~'.expand("<slnum>"))
+ call s:NetrwDelete(tmpfile)
+ endif
endif
call s:NetrwOptionRestore("w:")
I'm experiencing a very sluggish startup time with vim as well as other unrelated programs ever since I logged out and logged back in the last time. Following is the startuptime log for vim:
> times in msec clock self+sourced self: sourced script clock
> elapsed: other lines
>
> 000.005 000.005: --- VIM STARTING ---
> 000.073 000.068: Allocated generic buffers
> 000.168 000.095: locale set
> 000.180 000.012: GUI prepared
> 000.181 000.001: clipboard setup
> 000.188 000.007: window checked
> 000.621 000.433: inits 1
> 000.626 000.005: parsing arguments
> 000.627 000.001: expanding arguments
> 000.637 000.010: shell init
> 000.909 000.272: Termcap init
> 000.942 000.033: inits 2
> 001.031 000.089: init highlight
> 023.418 000.234 000.234: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syncolor.vim
> 023.543 001.811 001.577: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/synload.vim
> 044.397 015.231 015.231: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/filetype.vim
> 044.449 025.111 008.069: sourcing /grid/common/pkgs/vim/latest/share/vim/vim73/syntax/syntax.vim
> 052.532 000.199 000.199: sourcing /grid/common/pkgsData/vim-v7.3/Linux/RHEL4.0-2007-x86_64/share/vim/vim73/syntax/nosyntax.vim
> 059.858 000.175 000.175: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syncolor.vim
> 059.966 003.842 003.667: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/synload.vim
> 060.002 010.259 006.218: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syntax.vim
> 069.085 000.178 000.178: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syncolor.vim
> 072.326 000.173 000.173: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syncolor.vim
> 076.317 000.175 000.175: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/syntax/syncolor.vim
> 076.477 013.311 012.785: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/colors/desert.vim
> 079.768 000.019 000.019: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/filetype.vim
> 080.322 065.921 017.221: sourcing $HOME/.vimrc
> 080.330 013.378: sourcing vimrc file(s)
> 106.526 000.376 000.376: sourcing /home/haitham/.vim/plugin/genutils.vim
> 111.139 001.435 001.435: sourcing /home/haitham/.vim/plugin/multiselect.vim
> 113.534 000.147 000.147: sourcing /home/haitham/.vim/plugin/omap-param.vim
> 119.245 000.073 000.073: sourcing /home/haitham/.vim/plugin/qfixtoggle.vim
> 122.821 000.696 000.696: sourcing /home/haitham/.vim/plugin/surround.vim
> 172.247 000.098 000.098: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/getscriptPlugin.vim
> 176.387 000.252 000.252: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/gzip.vim
> 179.876 000.183 000.183: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/matchparen.vim
> 182.748 000.620 000.620: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/netrwPlugin.vim
> 186.171 000.051 000.051: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/rrhelper.vim
> 189.739 000.046 000.046: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/spellfile.vim
> 193.406 000.195 000.195: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/tarPlugin.vim
> 199.206 000.060 000.060: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/tohtml.vim
> 202.299 000.152 000.152: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/vimballPlugin.vim
> 205.345 000.147 000.147: sourcing /grid/common/pkgs/vim/v7.3/share/vim/vim73/plugin/zipPlugin.vim
> 205.394 120.533: loading plugins
> 12343.581 12138.187: inits 3
> 12349.592 006.011: reading viminfo
> 18421.239 6071.647: setup clipboard
> 18421.264 000.025: setting raw mode
> 18421.270 000.006: start termcap
> 18421.293 000.023: clearing screen
> 18421.504 000.211: opening buffers
> 18421.564 000.060: BufEnter autocommands
> 18421.566 000.002: editing files in windows
> 18425.833 004.267: VimEnter autocommands
> 18425.835 000.002: before starting main loop
> 18426.587 000.752: first screen update
> 18428.334 001.747: --- VIM STARTED ---
Apparently the biggest components are "inits 3" and "setup clipboard".
Any clues what to do about it?
setup clipboard
First, try running Vim with the following command:
$ vim -X
You can try using the -X --startuptime <file> options together to see if the "setup clipboard" component is still slow.
If -X helps, you can get the same effect by adding the following line to your vimrc file:
set clipboard=exclude:.*
Explanation
If this helps what is happening is that on startup Vim is trying to connect to an X server to allow it to use the clipboard. The -X option tells Vim to not try connecting to the X server. From :help -X
-X Do not try connecting to the X server to get the current
window title and copy/paste using the X clipboard. This
avoids a long startup time when running Vim in a terminal
emulator and the connection to the X server is slow.
See --startuptime to find out if affects you.
Only makes a difference on Unix or VMS, when compiled with the
+X11 feature. Otherwise it's ignored.
To disable the connection only for specific terminals, see the
'clipboard' option.
When the X11 Session Management Protocol (XSMP) handler has
been built in, the -X option also disables that connection as
it, too, may have undesirable delays.
The clipboard option can be used to achieve the same thing more permanently via your vimrc file. From :help 'clipboard'
To never connect to the X server use:
exclude:.*
This has the same effect as using the -X argument.
Note that when there is no connection to the X server
the window title won't be restored and the clipboard
cannot be accessed.
The clipboard=exclude:.* option can be refined to only work with particular terminals, if you want Vim to connect to the X server in some instances. Check out :help 'clipboard' for more on this.
For me, this problem was happening because I had "X11 Forwarding" enabled on my ssh client but did not always have an X Server running on the ssh client machine.
When I have an X server running on the target machine, Vim is much faster starting up (though still a bit slow).
In this setup, I want to maintain the X11 Forwarding, but do not need Vim to use the X clipboard, so I added the set clipboard=exclude:.* line to my vimrc. Now Vim startup is quick for me once more.
inits 3
You seem to have already eliminated your plugins/customisations as a possible cause by trying vim -u NONE (and you said your vimrc was empty).
I am not familiar with this issue, but as suggested above, it might be to do with your viminfo file.
You can determine whether this is the case by starting Vim with the following command:
$ vim -i NONE
According to :help slow-start:
If you have "viminfo" enabled, the loading of the viminfo file may take a
while. You can find out if this is the problem by disabling viminfo for a
moment (use the Vim argument "-i NONE"). Try reducing the number of
lines stored in a register with ":set viminfo='20,<50,s10".
I'm using v7.4. The -X option increase the startup time successfuly when vim compiled with +clipboard. But, since the connection to the X now disabled, we can't copy and paste from x clipboard anymore.
Meanwhile, vim is my only way to write before send it to email, twitter, telegram, etc. So copy+paste from vim is a must. Just found the simple solution :
alias v='nvim'
Nvim use my old .vimrc automatically. clipboard feature work seamlessly without any configuration hassle.
Not provoking to using nvim. I just found it the shortest solution to my problem now.
I am trying to open a 200MB text file in gvim on Windows, and it's choking. The vim window opens and just remains blank and unresponsive. My system has 8GB of RAM and the file opens fine in about 2-5 seconds using notepad.
I found this SO post on editing very large text files in vim, and I tried opening the file with plugins turned off:
vim -u "NONE" my200MBfile.text
But that didn't help. Is there anything else I can do to make it work? It seems strange that vim would choke on my machine on what is not really such a large file.
Thanks!
Most likely it's the syntax plugin that makes vim halt. I never have any issues with files of Mbs-Gbs. Unless I accidentally open them with some - not-so-well-behaved - filetypes.
Press ^C while loading/hanging (interrupting plugins)
:syntax off
Does the trick. There are other options with syntax that makes it easier to work with a file without fully 'synchronized' syntax highlighting
I played around with this some more, and I found indeed some of my plugins would make operating on (very) large files very slow. I did this, for fun:
On a large input file (~600Mb):
$ wc input.txt.full
2674568 2674568 608825278 input.txt.full
I launched vim with the following tweaks:
vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full
Note this
-u NONE prevents execution of initialization (user) scripts and plugins
-n disables the writing of swapfiles (extremely important on slow/small disks)
se nonu nowrap ul=-1 disables
line numbering
line wrapping
undo history (setting undolevels to a negative value)
Basically, everything that could take a lot of CPU or memory
syn off to disables syntax highlighing (should only make a difference if syntax highlighting was in effect for the file type)
Now, I wanted to duplicate each line on the line itself (globally: copy line, join with previous):
:g/^/t.|-j
Unfortunately, the file would become too large for available memory (~3Gb)1 so I opted to act on the first 20% (~535,000 lines):
:exec "norm 20%"|1,.g/^/t.|-j
This works in a "jiffy" and without problems. Manual navigation (jumps, scrolling, mode switching, searching etc.) seems to be responsive.
Commandline Benchmark:
$ xxd -c 44 /dev/urandom | head -n 3800000 > input.txt.full
$ wc input.txt.full
3800000 91820644 627000000 input.txt.full
$ time vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full +'exec "norm 10%"|1,.g/^/t.|-j' +wq
real 0m7.778s
user 0m6.680s
sys 0m0.952s
$ wc input.txt.full
3800000 101002757 689940307 input.txt.full
(Note that 689940307 ÷ 627000000 = 110.03 %, so that is exactly right).
This isn't slow in my book. For comparison, the wc invocation itself takes the same amount of time (7.7s).
1 All test performed on tmpfs to avoid cache differences.
The problem is more likely that vim doesn't like lines that long very much.
Try using a tool like json_reformat on the file first...
If you absolutely have to edit the file as-is, try :syntax off and possibly :set nowrap before you :edit the file in question.
Although Vim doesn't have a problem opening files of that size (or bigger), it is mentioned that it has a problem of opening a file with, as is your case, only one line (of that size).
You could try various workarounds, but I would suggest going with the "right tool for the right job" approach, and try EmEditor, a text editor made specifically for editing large files (amongst other things).
Note that this is not Vim bashing, but Vim is an editor for editing source code mostly. An excellent one at that, but like every other tool it has its limitations.
[using MacVim 7.3 on OS X Lion]
I have a vimscript function which runs an external command. It's executing correctly, but the output displays (unwanted) control characters, such as [0m, [33m, [36m, and -1H. The relevant line in the vimscript function is:
exec ":!bundle exec rspec --color " . a:filename
Which produces:
:!bundle exec rspec --color spec/acceptance/user_logs_in.feature
[33m*[0m
Pending:
[33m User logs in [0m
[36m # the step 'the user "foo#test.host" exists' is not implemented[0m
[36m # [0m
Finished in 0.07121 seconds
[33m1 example, 0 failures, 1 pending[0m
Here's what the same command and output look like from the terminal, which is how I want it to display in vim:
$ bundle exec rspec --color spec/acceptance/user_logs_in.feature
*
Pending:
User logs in
# the step 'the user "foo#test.host" exists' is not implemented
#
Finished in 0.1161 seconds
1 example, 0 failures, 1 pending
Also, any time I execute and external command, vim displays -1H immediately after it. For example, if I type:
:ls<return>
I see:
:ls-1H
<rest of the output is as expected>
Any ideas on hiding those control characters and -1H.
(disclaimer: I'm very new to vim so please don't assume too much background knowledge on my part.)
Thanks.
Update 3/31/2012 # 17:32 PM
Sam Goldman's correct: MacVim doesn't know how to display colors, so it outputs the color codes.
I've switched to terminal vim (which supports colors, at least with iTerm), but using the version of vim that comes with MacVim, which is more up-to-date and is compiled with ruby support (among other things). The easiest way to do that is:
brew install macvim --override-system-vim
MacVim doesn't know how to display colors. Terminal vim will display the colors correctly, or you can add --no-color to your rspec command (or a .rspec file). I'm not sure about the -1H thing. Maybe some customization you have for your terminal?
I'm using VIM 7.1 on Debian. I have 9 plugins that I load via pathogen.vim. It takes around 8 sec's to load which is quite slow since this is in non-GUI/xterm mode. I ran vim -V and it shows that each module is being searched for in multiple directories.
Initially, ftoff.vim, debian.vim and other "system" related .vim files are searched for in ~/.vim/ and then in /usr/share/vim/vim71/ - I fixed this by moving my .vimrc to .vim/vimrc and: export VIM=/root/.vim, within .vimrc i did a set runtimepath=/usr/share/vim/vim71
But now, when the modules load, they alter this runtimepath and when pathogen loads it's even worse. Is there a way to specify a hash of module-name to dirPath so that this error prone lookup is avoided? Or a way to manually specify runtimepath on a per module basis within vimrc?
Here is an example of my runtimepath after pathogen loads my modules. Obviously, any further loading of a module invovles searching all those pathnames before locating the right path.
runtimepath=~/.vim,~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bu
ndle/The_NERD_Commenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/pathogen,~/.vim/bundle/vim-addon-mw-utils,
/.vim/bundle/tlib,~/.vim/bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist
~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bundle/pathogen,~/.vim
bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist,~/.vim/bundle/The_NERD_C
mmenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/tlib,~/.vim/bundle/vim-addon-manager,~/.vim/bundle/vim-add
n-manager-known-repositories,~/.vim/bundle/vim-addon-mw-utils,/var/lib/vim/addons,/usr/share/vim/vimfiles,/u
r/share/vim/vim71,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/bundle/snipMate/after,~/.vi
/after,~/.vim/bundle/snipMate/after
I use vim-addon-manager and have 33 paths in rtp, but it takes around 0.7-0.8 seconds to start and immideately close vim (with vim -c 'qa!'), so the problem is either one of the plugins or your system. To check how long it takes to load each plugin, try the following script:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profdel func *' \
-c 'profdel file *' \
-c 'qa!'
You will get all timings in the profile.log. Table with function timings will be
present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of
profile.log, but 1) for scripts, not for functions, 2) unsorted.
If problem is your system, you may try the following:
When computer starts create a ram disk and mount it to ~/.vim, then copy all plugins there.
Try merging plugins into a single file, see :h scriptmanager2#MergePluginFiles() (vim-addon-manager must be activated)
Upgrade your computer
Try creating a hardlinks to all plugins in ~/.vim:
cd ~/.vim/bundle;for d in *;do cd "$d";for f in **/*.vim;do t="$HOME/.vim/$(dirname "$f")";test -d "$t"||mkdir -p "$t";ln "$f" "$t";done;cd ..;done
it might not be related, but for me the variable DISPLAY makes a big difference in the time it takes to start vim (even when I have vim compiled without gui).
Try with
DISPLAY= vim
and
DISPLAY=:0 vim
and see if you notice a difference.
http://pastebin.com/R6E4czN7
I've pasted the output of vim -V to pastebin (should be valid for 1 month). It's self explanatory. There are a gazillion searches(414 search lines - most of them are useless). I need to reduce the number of incorrect searches.
1297651453.71068: Searching for "/root/.vim/bundle/pathogen/autoload/scriptmanager.vim"[J
1297651453.71456: Searching for "/root/.vim/bundle/snipMate/autoload/scriptmanager.vim"[J
1297651453.71846: Searching for "/root/.vim/bundle/SuperTab/autoload/scriptmanager.vim"[J
1297651453.78737: Searching for "/root/.vim/bundle/surround/autoload/scriptmanager.vim"[J
1297651453.79179: Searching for "/root/.vim/bundle/taglist/autoload/scriptmanager.vim"[J
1297651453.79684: Searching for "/root/.vim/bundle/The_NERD_Commenter/autoload/scriptmanager.vim"[J
1297651453.80756: Searching for "/root/.vim/bundle/The_NERD_tree/autoload/scriptmanager.vim"[J
1297651453.83: Searching for "/root/.vim/bundle/tlib/autoload/scriptmanager.vim"[J
1297651453.86193: Searching for "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.8662: line 3: sourcing "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.88259: finished sourcing /root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim[J