I am a happy user of VIM, except for some bits which I really want vim to improve on. One main issue is frequent slowdown of VIM spoiling the amazingly productive text-editing experience on a fastest desktop PC that one can find and a fresh linux installation. This is more with after start-up than during start-up.

Finding the causes of slowdown is a big headache: it could be .vimrc or plugins or too many syntax highlighting or number of buffers etc. None of these reasons make sense to me given a gaming PC that runs multiple graphics engines. After all, I am working with plain text not 3D graphics! At least vim must not be any slower than the basic utilities gedit or notepad!! I will proceed with these reasons anyway.

To highlight, two of the main reasons that I find for this popular slow down are:

  1. Syntax highlighting (this is surprising, given the fastest processors these days)
  2. Too many redraw (refresh) operations by any means

    2a. I actually assume having any number of buffers open must not cause vim to slow down. But this also has been a case where I notice a significant slow down. We deal with one buffer at a time after all!

Some specific solutions that I found so far are:

  1. Removing :set relativenumber and also :set cursorline since they cause too many redraws. (yes it is a silly reason, given fastest processors and GPUs these days! But rest of the reasons are no less. And brace yourselves, you have too many of them.)

  2. Add :set regexpengine=1 According to this answer, Vim 7.4 has introduced a weaker regex engine and setting this option will revert it to older, causing a significant speed up.

  3. Add :set lazyredraw and :set ttyfast Instructs the vim engine to try redrawing as fewer times as possible.

  4. Add :syntax off -- remove so that vim doesn't need to work on colouring keywords etc! (its indeed a radical solution, but at least will tell you how serious the syntax is and also whether it is actually the reason)

  5. Current folding method could be a cause of the slow-down, especially if it is syntax or expr. (i.e. change :set foldmethod=syntax or :set foldmethod=expr to something else)

  6. Autocommands. Disable everyone of them in your vimrc and see if it improved the speed. Having too many parallel processes like autocommands, on a single-thread machine like Vim can cause a significant slow down.

  7. Try :set synmaxcol=xxxx (as per romainl's answer) with xxx a number less than the default value of 3000. e.g. 200.

  8. You might be having too many plugins, with unknown lags. So go for a trial-and-error to find out the culprit plugin and remove it.

  9. You might be having a number of buffers open, try removing some using bd

  10. Like many older systems, ageing might be a problem, especially when dealing with multiple buffers open. Agreed on having no clue about the root cause of the problem, simply restart VIM and one often sees a significant improvement.

  11. Try restarting vim with no plugins and vimrc using >> vim -u NONE -U NONE -N, see if it solved the problem.

  12. Finally, start a profiler (many ways to do this!) as mentioned in one of the answers below and break your head until you find the reason.

In a nutshell, My main question is this:

Can somebody tell me how can a willing practitioner actively avoid the most annoying vim's slowdown? (Hopefully in a user friendly non-geeky way) -- All I want is a simple, ready-to-use, fast plain-text editor!!

For the recent NeoVim alternative, I am not fully satisfied while I tried using it. I am not sure if it solves any existing problems but as I notice it does create new problems of interfacing and transition.

I know there are a number of questions on this, I paste them below. Hope this post serves as a starting point Wiki for all these problems. It is unfortunate that none of them are a single point of resource useful for this most popular problem within vim community. Hope this question becomes one!

  1. How do I debug my vimrc file?
  2. Vim slows down over time with syntax on
  3. Improve performance of syntax highlighting in Vim
  4. Vim response quite slow
  5. Syntax highlighting causes terrible lag in Vim
  6. How to see which plugins are making Vim slow?
  7. Vim slow with ruby syntax highlighting
  8. Enabling syntax and syntax folding in vim with large C file makes completion slow
  9. Syntax highlighting causes terrible lag in Vim


To claim some final words, it is a pity. Especially given the popularity and the number of fan-boys within the tech community, plus the number of active projects at any point of time ever since Unix. Vim, while being arguably the most useful programmable text editor on earth, lies down in an old-age single-threaded implementation with minimal configurable teletype appearance and many other rusty functionalities as I hear from techie friends. I wish to know that I am wrong with some of these understandings.

I have never contributed to Open source, but I am an enthusiastic basic programmer with love for open source. Once I learn how to, I will make sure vim will bear at least one of my contributions to ail these problems.

  • 1
    If you look at the Neovim project you can see the absence of apathy. But that part of your "question" was as confusing as the rest of it, to be honest. Even Vim has seen a lot of changes recently. You've failed to demonstrate what this "frequent slowdown" is. (I use vim happily ssh-ing to a raspberry pi). Perhaps you could provide a specific example of how to reproduce it, and state your PC's spec?
    – user859
    Dec 6, 2016 at 15:48
  • 3
    I'm not sure what answer you're looking for here; you've already identified several potential causes of performance problems. That didn't fix your problem? Or you have some other problem? If so, then provide us with the information we need to try and answer it. Right now I don't really see an actual question in this question, and it seems more like a rant to me ("frequent slowdown of Vim" is not a question, but an observation; you'll need to provide more specific details). Dec 7, 2016 at 12:02
  • NOTE: It's highly dependant on the operating system and terminal also; The problems move when you move OS, Terminal, whether you work via SSH or not. I found that Mac and Terminal.app in particular had a very slow redraw compared to MacVim. Different terminals produce different results. WSL also typically needs a special treatment, though getting much better. Another thing is plugins, but you should be able to pinpoint the issue by removing one by one. You can create conditions like if ($SSH_CLIENT || $SSH_TTY) with stuff like set lazyredraw set number noshowcmd set nocursorline
    – dza
    Jan 8, 2020 at 5:31

1 Answer 1


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 my own older and very limited Mac Mini, Vim is quite possibly the most responsive app.

Anyway, Vim is an old program with an old single-threaded architecture. This obviously comes with a few limitations.

The biggest performance hits come from the syntax highlighting mechanism which is based on regular expressions. Unfortunately, regular expressions are quite hard to get right and are not really the best tool for the job anyway. Some built-in syntax scripts like PHP, YML, and Ruby are notoriously slow. Whether that slowness is due to sloppy programming on the maintainer side, a bad regex engine, or the very idea of using regular expressions in the first place is up for the debate.

Some common workarounds:

:syntax off                      " radical
:set synmaxcol=200               " arbitrary number < 3000 (default value)
:set foldmethod=manual           " anything other than 'syntax'
:set foldmethod=indent           
:set noshowmatch                 " it's off by default but well

Another performance hit comes with a general misunderstanding of autocommands. It's very easy to have them pile up and end up with tens or hundreds of them executed before and/or after any operation (remember Vim is single-threaded), resulting in a progressive slow down. It's also very easy to read the documentation and write your autocommands properly. No workaround needed:

augroup myautocommands
    autocmd SomeEvent,AnotherEvent pattern command
augroup END

The third biggest performance hit is caused by redrawing, which happens in the main thread, like everything else. Redrawing often is not a problem if you don't have much to redraw (try $ vim -Nu NONE file.rb) but people want a fancy statusline, fancy gutter signs, more colors, side panels and all kinds of pointless gadgets and they insist on scrolling with jk.

Also, did I mention that Vim is single-threaded? The more you ask it to do "automatically", the slower it gets.

All I want is a simple, ready-to-use, fast plain-text editor!!

Then contribute code or use nano.

  • I am confused. Can you please clarify: Are you saying that 1. VIM is the fastest possible application and no solutions needed? -- But you already mentioned problems like it being single threaded against contemporary applications!! 2. Its people bad practices not VIM itself that is the reason for its slow speed? -- But all you mentioned are the default utilities!! 3. The reasons are inevitable and must live with? -- you already mentioned some solutions!! Dec 4, 2016 at 10:42
  • 2
    I'm saying 1. that some issues can be avoided if you configure Vim properly, 2. that some other issues have low-level causes and practical high-level workarounds, 3. that if you want Vim to not have those issue you are welcome to contribute to the project. No contribution == no right to complain.
    – romainl
    Dec 4, 2016 at 10:50
  • 1
    Regarding common workarounds: slowness can also come from setting 'foldmethod' to expr.
    – garyjohn
    Dec 4, 2016 at 17:35
  • The biggest performance hits come from the syntax highlighting mechanism which is based on regular expressions.: would it be possible to rewrite the concerned source code to make it use a better mechanism than regex? I've never looked too close at the source code so my question might be pretty dumb. I'm also aware that there are a few examples of patches not being merged because Bram don't like them but on a purely technical point of view (and regardless of the amount of time it would take to develop the patch) would it be possible?
    – statox
    Dec 5, 2016 at 12:18
  • 4
    @statox There are many things that could be done in Vim to speed up syntax highlighting. Most of them would either break compatibility with Vi, or would prevent users from defining highlighting for new languages, but there are indeed a few things that can't be done because of the way Vim is structured. Neovim didn't address that, Elvis did. But, as most of us know by now, Elvis is dead. :/ Aside from that, syntax highlighting with regexes is ok, but some languages are more pathologic than others (Ruby, JSON, and YAML being easy examples).
    – lcd047
    Dec 7, 2016 at 18:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.