GVim Win32 on Win7 suddenly very slow to load
Greg Underwood
I found the threads on scripts and other startup time issues, as well as using --startuptime. The scripts seem unlikely to be a problem - they haven't changed and the same install runs fine from Cygwin command line startup. I went ahead and nuked _viminfo - but that didn't help. So I ran both the Win32 shortcut and Cygwin command line with the --startuptime option. When I compare them there are a lot of differences - many (but not all) of the .vim file sources run a lot slower (increases of hundreds to thousands of msecs), and 'starting GUI' jumps from almost nothing (030.000) to the worst single offender (6625.000).
Any ideas on how I can track down what's up and (hopefully) fix it?
Cheers,
-Greg
Ben Fritz
Does your Windows shortcut run a cygwin gvim? I'm not sure where
cygwin fits into this picture, otherwise.
You do know there is a native Vim installer for Windows, right?
I'm wondering if the extra startup time for the shortcut might have to
do with starting the cygwin environment or something. Really you've
given almost zero detail as to what your setup is.
What options do you pass Vim? What version of Vim are you running? Are
you launching the same Vim executable from your shortcut as from
cygwin? If not, is it the same version? Do they use the same startup
files?
Greg Underwood
> Does your Windows shortcut run a cygwin gvim?
> I'm not sure where cygwin fits into this picture, otherwise.
> You do know there is a native Vim installer for Windows, right?
> I'm wondering if the extra startup time for the shortcut might have to
> do with starting the cygwin environment or something.
> Really you've given almost zero detail as to what your setup is.
> What options do you pass Vim? What version of Vim are you running? Are
> you launching the same Vim executable from your shortcut as from
> cygwin? If not, is it the same version? Do they use the same startup
> files?
My setup is:
System:
Win7 64-bit, running as dual-boot on an apple iMac. The problem is only occurring on the Windows side of things, and as stated, only started to occur on Friday, after updating some Windows software. (Apologies for calling it Win32 originally - long-standing habit I should really break).
I do have the Mac version 7.3 of GVim installed on the Mac side and all is well there - no slow downs.
Installed Vim:
Win32 version 7.3.46 of GVim installed via native installer for Win32, installed into C:\Program Files (x86)\Vim\...
The Windows shortcut is a direct shortcut to the native-installed GVim for Win32 - C:\Program Files (x86)\Vim\Vim73\gvim.exe
Cygwin config:
Cygwin installed - no version of vim installed from the Cygwin packages - I didn't want parallel installations and any conflicts that might arise therefrom.
Cygwin's $(HOME)/.bashrc has an alias mapping 'vi' to the Win32 native install of GVim (same path as above).
I only set up one _vimrc file, in C:\Program Files (x86)\Vim\_vimrc
When I run:
When I launch GVim from both the Windows shortcut or right-click context menu and from the Cygwin command line, it is obviously using the same _vimrc file as my settings are different enough from the default to be immediately obvious if GVim is loading with them or not (different background color, bigger window, etc).
My assumption is that they are therefore sharing all the same config files and that I really am launching the same executable with the same config.
Is there a way I can ask GVim to tell me what all config files (with full paths) it's using on startup to confirm this?
GVim is launched with no options on the command line - just a file name when I'm editing a file, or no options at all when launching a new, blank window.
Other info:
I mentioned Cygwin because, as far as I can tell, it's launching the same executable with the same config files, but is doing it orders of magnitude faster. Which seems very interesting, but I'm not sure how to interpret. It certainly seemed relevant to the discussion. :)
-Greg
Ben Fritz
Probably this won't matter, but that version IS quite old. There's
more recent native installers available, or you can compile your own
if you're so inclined. At work I just download the installer:
http://sourceforge.net/projects/cream/files/Vim/
> Cygwin config:
>
> Cygwin installed - no version of vim installed from the Cygwin packages - I
> didn't want parallel installations and any conflicts that might arise
> therefrom.
> Cygwin's $(HOME)/.bashrc has an alias mapping 'vi' to the Win32 native
> install of GVim (same path as above).
>
Hmm, interesting. I'm not certain how well this will work. Apparently
it mostly works fine for you, though with some slow-down on the
Windows side.
> I only set up one _vimrc file, in C:\Program Files (x86)\Vim\_vimrc
>
> When I run:
>
> When I launch GVim from both the Windows shortcut or right-click context
> menu and from the Cygwin command line, it is obviously using the same
> _vimrc file as my settings are different enough from the default to be
> immediately obvious if GVim is loading with them or not (different
> background color, bigger window, etc).
>
> My assumption is that they are therefore sharing all the same config files
> and that I really am launching the same executable with the same config.
> Is there a way I can ask GVim to tell me what all config files (with full
> paths) it's using on startup to confirm this?
>
:scriptnames should do it. Also try to :echo &runtimepath to see where
it looks for everything. But I'm guessing you made a decent
assumption.
> GVim is launched with no options on the command line - just a file name
> when I'm editing a file, or no options at all when launching a new, blank
> window.
>
So, probably no filetype-specific plugins interfering.
> Other info:
>
> I mentioned Cygwin because, as far as I can tell, it's launching the same
> executable with the same config files, but is doing it orders of magnitude
> faster. Which seems very interesting, but I'm not sure how to interpret.
> It certainly seemed relevant to the discussion. :)
>
I'd start by narrowing it down to plugins vs. your .vimrc. Try all of:
gvim -i NONE (to check for the .viminfo/_viminfo file containing
something ridiculous)
gvim -N -u NORC -i NONE (to check for .vimrc/_vimrc causing it)
gvim -N --noplugin -i NONE (to check for plugins causing it)
gvim -N -u NONE -i NONE (to check all your config at once)
Christian Brabandt
> My assumption is that they are therefore sharing all the same config files
> and that I really am launching the same executable with the same config.
> Is there a way I can ask GVim to tell me what all config files (with full
> paths) it's using on startup to confirm this?
Check the output of :scriptnames
> GVim is launched with no options on the command line - just a file name
> when I'm editing a file, or no options at all when launching a new, blank
> window.
>
>
> Other info:
>
> I mentioned Cygwin because, as far as I can tell, it's launching the same
> executable with the same config files, but is doing it orders of magnitude
> faster. Which seems very interesting, but I'm not sure how to interpret.
> It certainly seemed relevant to the discussion. :)
If you installed Vim using the Cygwin setup.exe, you usually get a
completly different exectuable. But it is possible, to start
the same Windows built using Cygwin.
regards,
Christian
Christian Brabandt
> I'd start by narrowing it down to plugins vs. your .vimrc. Try all of:
>
> gvim -i NONE (to check for the .viminfo/_viminfo file containing
> something ridiculous)
>
> gvim -N -u NORC -i NONE (to check for .vimrc/_vimrc causing it)
>
> gvim -N --noplugin -i NONE (to check for plugins causing it)
>
> gvim -N -u NONE -i NONE (to check all your config at once)
Also there is a faq on it:
http://vimhelp.appspot.com/vim_faq.txt.html#faq-36.12
regards,
Christian
George V. Reilly
If your scripts and vimrc haven't changed but your Windows has,
ProcMon [1] may help pinpoint what's going on.
[1] http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
--
/George V. Reilly geo...@reilly.org Twitter: @georgevreilly
http://www.georgevreilly.com/blog http://blogs.cozi.com/tech
Reid Thompson
> Probably this won't matter, but that version IS quite old. There's
> more recent native installers available, or you can compile your own
> if you're so inclined. At work I just download the installer:
>
> http://sourceforge.net/projects/cream/files/Vim/
(g)vim downloads are here
http://www.vim.org/download.php
Self-installing executable
ftp://ftp.vim.org/pub/vim/pc/gvim73_46.exe
Ben Fritz
Yes, you are correct these are the "official" sources. However, Bram
mostly only releases an installer for base version updates, e.g. 7.1,
7.2, 7.3... and only in rare circumstances does he ever release an
installer for the many patches generated between versions. Currently
the latest installer available from vim.org is one of those rare
circumstances, and includes patches up to number 46. There are now 364
patches available.
As a service, Steve Hall, the maintainer of the "Cream" project which
transforms Vim into a point-and-click editor, also releases installers
for fully patched Vim with all the latest runtime files, WITHOUT his
Cream config. This is the link I gave above. It's not official, but
it's pretty darn close, and is the de facto standard place to grab an
up-to-date Vim installer.
Reid Thompson
> As a service, Steve Hall, the maintainer of the "Cream" project which
> transforms Vim into a point-and-click editor, also releases installers
> for fully patched Vim with all the latest runtime files, WITHOUT his
> Cream config. This is the link I gave above. It's not official, but
> it's pretty darn close, and is the de facto standard place to grab an
> up-to-date Vim installer.
cool -- i ;) didn't realize that the cream project packaged a 'vanilla'
vim -- that's awesome and good to know going forward.
Greg Underwood
Interestingly, it seems to have returned to full speed now, after rebooting a couple more times. I had rebooted the system once or twice while installing the updates, and saw the behaviour after the reboots. So I rebooted again to check if one more reboot would fix the issue (as far as Win7 has come, it still needs a swift kick in the reset button sometimes), with no luck. ... But as of today it seems OK again.
Very odd.
Perhaps Windows was doing some heavy-duty indexing in the background ... that took 5 days ... to resolve... ?
I dunno. Very very odd.
I'll look into ProcMon - maybe it would have revealed what Win7 was up to and I could have saved us all some time and random flailing about. :P
Thanks everyone! For now, I think we can call this resolved (?) by the dark power that is the Repeated Windows Reboot... :/
-Greg
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Greg Underwood
Knowing that there's someone out there who rolls a package with the basic VIM stuff, but up to date, is worth looking into!
Cheers,
-Greg
Ben Fritz
On Dec 6, 11:44 pm, Greg Underwood <greg.underw...@gmail.com> wrote:
> Good to know! I have mostly stuck with the tried-and-true official
> releases from vim.org, which I know are behind the times a bit. Unless VIM
> starts misbehaving, I'm cool with sticking to the official releases - my
> editor is my dialtone - not something I tinker with unless it ain't working
> or there's a clearly much better one available. :D
>
> Knowing that there's someone out there who rolls a package with the basic
> VIM stuff, but up to date, is worth looking into!
>
You can see what you'd be getting if you upgraded, here:
ftp://ftp.vim.org/pub/vim/patches/7.3/README
There are a few really nice goodies in there, plus some easy-to-get
errors which have been fixed.
Also, if you upgrade, you'd be getting an all-new set of runtime
files, including improved syntax highlighting, better TOhtml
conversion, bugfixes in the netrw plugin (used to "edit" directories
on local or remote systems, or files on remote systems via FTP or
other protocols), and much more.
George V. Reilly
KF
> Starting after I upgraded to VisDev 2010 and applied a couple of the recent
> patches for Win7 yesterday and today, my Vim is very slow to load when
> launched from my windows shortcut. However, it's very fast if I launch
> from a Cygwin command line.
>
I do have the same problem of GVim takes a long time to start-up,
~6-8s to get the screen shown which previously was working snappily. I
also have the same problem when saving/writing changes to disk. It
takes ~10s to even write the file!
Looking at the Task Manager, it seems that the MS Security Essential
is the culprit that is causing the behaviours. Turning off MSSE's real-
time protection seems to make it to start-up and saving files quicker.
Just some observations...
KF
KF
Other people also seeing the same problem:
http://code.google.com/p/vim-win3264/issues/detail?id=7
The problem of takes long time to write to disk, it seems that it's
Vim's fault. Using Vim 7.3.372 (without Cream version).
Details:
I have an autocmd to strip white spaces from end of line when writing
to disk, which was taken from Vim wiki:
autocmd FileType c,cpp,java,php,txt autocmd BufWritePre <buffer> :call
setline(1,map(getline(1,"$"),'substitute(v:val,"\\s\\+$","","")'))
When saving, Vim takes ~50% of the CPU cycles for ~5s before it
settles down and display write complete message.
I have changed the above autocmd to:
function TrimSpaces()
%s/\s*$//
''
:endfunction
autocmd FileType c,cpp,java,php,txt autocmd BufWritePre
<buffer> :silent! call TrimSpaces()
This time CPU cycle consumption is normal, no spikes; and it responds
almost instantly (>8000 lines of code).
Anybody can check and verify this behaviour?
KF
KF
John Beckett
> I have an autocmd to strip white spaces from end of line when
> writing to disk, which was taken from Vim wiki:
>
> autocmd FileType c,cpp,java,php,txt autocmd BufWritePre
> <buffer> :call setline(
> 1,map(getline(1,"$"),'substitute(v:val,"\\s\\+$","","")'))
Commenting on the tip, not the problem:
That command seems particularly silly, and it is has been in the
tip for quite a long time.
http://vim.wikia.com/wiki/Remove_unwanted_spaces
Just prior to that in the tip, it offers the following which is
obviously the correct method:
autocmd BufWritePre * :%s/\s\+$//e
Assuming no one can identify a brilliancy in the setline, the
tip should be edited to use the :%s approach.
Commenting on the problem: The setline method uses every
possible trick to force Vim to do the the maximum amount of
work, and for a file of significant size, I imagine a very large
amount of RAM is used. I wonder if Vim would make temp files for
some processing in this case. If so, anti virus scanning could
be compounding the problem.
John
Christian Brabandt
On Fr, 16 Dez 2011, KF wrote:
> Details:
> I have an autocmd to strip white spaces from end of line when writing
> to disk, which was taken from Vim wiki:
>
> autocmd FileType c,cpp,java,php,txt autocmd BufWritePre <buffer> :call
> setline(1,map(getline(1,"$"),'substitute(v:val,"\\s\\+$","","")'))
That is absolute unnecessary and let's Vims memory consumption rise
dramatically. I can't think of why one would want such an autocommand.
Apart from the memory issue and that it is hard to read, it is a lot
simpler to use :%s/\s\+$//
> Anybody can check and verify this behaviour?
Yes. Simply don't use that autocommand.
regards,
Christian
--
Nun, wo flie�t Petersburg hin? Petersburg flie�t in die Ostsee.
-- Johann Georg August Galletti