31
Vim has a built-in profile set of commands. See :h profile.
You would open up vim, and then run the following
:profile start profile.log
This sets up the file profile.log to be the log file. If it already exists, it will be overwritten. We now need to tell vim what to profile
:profile func *
:profile file *
This says to profile all functions and all ...
23
I can reproduce this with the syntax/python.vim that ships with Vim 7.4.663.
Using :syntime, this seems to be caused by the following syntax group / pattern:
TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
73.870736 20 0 3.940215 3.693537 pythonNumber \%(^\|\W\)\@<=\d*\.\d\+\%([eE][+-]\=\d\+\)\=[jJ]\=\>...
17
Can somebody tell me how to avoid the very annoying vim's slowdown? Hopefully in a user friendly non-geeky way?
I run Vim on a company-provided 2013 15" Retina MacBook with a 2.3 GHz i7 processor, 16 GB of RAM, and a measly GT 750M with 2 GB dedicated memory. That machine is very far from a "gaming PC" and I've never experienced any slow down. Ever. Even on ...
17
If you just want to see what's consuming start up time, then you can use the --startuptime option.
vim --startuptime timing.out
The file will look like this:
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
000.000 000.000: Allocated generic buffers
000.000 000....
14
Recent Vim versions have a :syntime command to troubleshoot slowness of syntax highlighting by generating a report of how long each syntax group takes to match. This is very helpful and quickly lets you find the culprit; the only downside is that you need a (usually "HUGE") build of Vim with profiling enabled. :help :syntime provides good instructions how to ...
12
This isn't really possible. Vim doesn't have any concept of isolation, everything lives in a big, happy, single-threaded process, and resources are democratically shared among all plugins. The best you can do is enable profiling (see :help profiling) and see which functions take the most time to run, but that won't tell you much about either CPU or memory ...
9
First: Did you bother to read the vimtex documentation, i.e. :h vimtex-folding? The docs clearly point out that the fold-expr method of folding is slow, and so therefore provides an option g:vimtex_fold_manual which if enabled (set to nonzero value) will set foldmethod=manual, and instead will remap zx and zX to recalculate the folds when necessary (...
6
The culprit in this particular situation was the Syntastic plugin.
It's forking eslint.
I load Syntastic on entering insert mode (using a vim-plug function loader).
Vim is plenty snappy on its own.
6
The slowness of delimiter matching is not caused by vim itself but by the matchparen plugin, which is part of the vim distribution and loaded by default in /etc/vim/vimrc in Debian. (This is why I still had the problem without a vimrc.)
Fortunately the matchparen plugin supports a timeout when looking for matches, so the slowness can be avoided by setting ...
5
Another typical bottleneck in vim's syntax highlight is folding. Editing can become very slow if a fold contains many syntax items (which basically means it goes over many lines), because vim will refresh all syntax for every inserted character.
If this is what you are experiencing then I suggest the use of FastFold plugin. This plugin identifies syntax ...
5
If your emails have a particular file type, you could use BufRead or BufNewFile or FileType to turn off some matchpairs automatically:
au BufRead,BufNewFile *.email set mps-=<:>
4
I had a problem a while back with syntax folding PHP where typing { would interfere with subsequent folds until I typed the corresponding closing }. I found a suggestion somewhere (I think it was on the Vim Wiki) to temporarily set the foldmethod to manual while in insert mode. I don't know if this is à propos enough to make an answer rather than a comment, ...
4
You can debug startup time by using the built in Vim profiler (tutorial)
If your version of vim is compiled with :profile you can run:
vim --cmd 'profile start vimrc.profile' --cmd 'profile! file ~/.vimrc'
If not, your stuck debugging it manually by adding and removing plugins and seeing where the long startup times are coming from.
I personally don't ...
4
As far as I can tell, your recording doesn't include any vertical motion. This means that 2@q will play your recording twice on the same line.
You could add a j at the end of your macro to move down.
Or you could use 2:norm @q to play your recording on the current line and the following one.
The "count" you give to Vim before running an ex command is ...
4
If you are debugging plugins, then do the following:
Disable half of your plugins.
If it fixes the problem, re-enable half of the disabled ones.
If it doesn't, disable half of the ones not yet disabled.
Repeat until you have proven which plugin is the cause, or that none is.
Your happy case is found by running vim -u NONE.
If that does not suffer from the ...
3
I did a search on GitHub and Google. From the results, it's pretty reasonable to assume that that function is from vim-css-color, which isn't in vim-polyglot.
In fact it looks like it was removed in 2015 for performance reasons. Are you sure you're using the most recent version of vim-polyglot?
3
I have seen this problem in other plugins as well (and some take a LOT more than 0.04 seconds).
The issue appears to be that Vim puts the terminal into "cooked" mode so that the command that is run can receive interrupt signals (from ctrl+c). This means that, for the duration of the command, your terminal is in line-editing mode. You can try this yourself ...
3
Switch to the old regexp engine, it's much faster than the new one for the particular regexp you're using:
set regexpengine=1
You can also turn off stuff you definitely won't be using (cf. wiki), but that will have a much smaller effect that the regexp engine. To sum it up, run ex with the following vimrc:
set regexpengine=1
set eventignore+=FileType
set ...
2
perhaps there's a way to use a mapping to turn fdm=manual before autocomplete or some such?
Well, this does that:
inoremap <C-x> <Esc>:setlocal foldmethod=manual<CR>a<C-x>
autocmd CompleteDone * :setlocal foldmethod=expr
autocmd InsertLeave * :setlocal foldmethod=expr
We remap <C-x> to first set the foldmethod to manual ...
2
Maybe one approach could be
vim --startuptime vim.log
Then you can sort vim.log output to get the most time consuming plugin. You can then profile vim startup with
vim -c 'profile start vim.log' -c 'profile func *' -c 'q'
This is rather verbose, but will print every function loading time, this way you can measure which function/plugin delay vim loading.
...
2
I have no idea if any of the following will help, but here are a few things you could try.
You have the following autocmd:
:au BufWinEnter * let w:m2=matchadd('ErrorMsg', '\%>85v.\+', -1)
I can't read your whole vimrc file, so maybe you already did it in the missing part, but in case you didn't, you should probably wrap this autocmd (and the other ones)...
2
My vim was slowing down because of Plugin 'Yggdroot/indentLine'. @laktak you was right
2
When you define a multi key mapping that starts with character that is itself a mapping, vim doesn't know which one you want after only the first character. It waits to see if you'll type another character indicating the longer mapping. If you don't type anything, after some time it will use the shorter mapping.
You can change the amount of time it waits by ...
2
There is nothing built in. But you might check lh-vim-lib.
It has the following functions working on sorted lists:
lh#list#equal_range()
lh#list#lower_bound()
lh#list#upper_bound()
1
You can profile and measure time Vim spends on executing functions and scripts. For more details, run :h profile in Vim.
Here's an example:
profile start ~/vim-profile.log
profile file ~/.vim/*
profile func foo#*
This will profile functions that start with foo# under ~/.vim/ and log the output in ~/vim-profile.log.
1
Most likely you have something in your actual syntax files causing the lag.
I'd reccomend running :syntime on, moving about a little, then doing :syntime report. This'll show you what patterns take the longest to check for matches. Consider disabling those, or looking them over if they're custom (usually stored in ~/.vim/after/)
1
I believe it is fine to use either :put or setline(). But as you are reading the contents from an external program, you could consider :read !:
:[range]r[ead] [++opt] !{cmd}
Execute {cmd} and insert its standard output below
the cursor or the specified line. A temporary file is
used to store the output of the command ...
1
First, addressing the low level issue…
There's no flickering at all in the popup menu, no matter how long it is or if cursorline and/or cursorcolumn are enabled or not.
Flickering only happens in YCM (and possibly other bloated "autocompletion" plugins) where — judging by the volume of flicker issues — it is a very common annoyance. I'd suggest trying to ...
1
I guess it has something to do with your .vimrc somewhere else, I can still edit emails as long as 10000 lines without having any slowdown with
set matchpairs+=<:>
Can you try with an empty vimrc and start finding out by commenting out other things ?
Only top voted, non community-wiki answers of a minimum length are eligible
