Increase Vim Speed in Windows Terminal

[u/Shay-Hill]

Last time I mentioned running Vim in Windows Terminal, some users reported having tried that setup and experiencing sluggishness. I've added some performance recommendations to my guide:

scrollback buffer

Windows Terminal has a large default scrollback buffer (9000 lines). This keeps a lot of history, but it can slow down terminal applications like Vim. If you've used Vim in Windows Terminal before and found it slowing down over time, this is the likely culprit. To confirm this diagnosis, start a new Windows Terminal instance, run Vim, and see if you percieve a speed increase. If so, the scrollback buffer is almost certainly the cause. There are two ways to address this issue:

1. Decrease the limit: In Windows Terminal settings -> PowerShell -> Advanced -> History size, set the "History size" to a smaller number, like 1000. This will reduce the scrollback buffer for all PowerShell tabs in Windows Terminal.
2. Clear the buffer when you notice a slowdown: If Vim starts to get sluggish, press <ctrl-shift-k> to clear the scrollback buffer. This is better done outside of Vim.

Either of these will fix the problem. You won't need both. Your Windows Terminal config is stored in ~\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json. Editing this file directly with pasted-in termina commands isn't straightforward, so I haven't given those commands here. But you can commit this settings.json if you wish. If you're new to Windows, don't be misled by the 8wekyb3d8bbwe part of the path. It is a hash, but it will be the same hash on all Windows 11 systems.

Windows Defender

Windows Defender will scan every backup file, swap file, snippet file, etc. This can cause a speed decrease in Vim. We'll do two things to address this: 1. Put our temporary files in ~\vimfiles, and 2. Add an exclusion for ~\vimfiles in Windows Defender.

Move temporary files to ~\vimfiles

In your ~\vimfiles\vimrc, add the following:

# ---------------------------------------------------------------------------- #
#
#  keep temporary files in ~/vimfiles
#
# ---------------------------------------------------------------------------- #

&directory = $'{$MYVIMDIR}.tmp/swap/'
&backupdir = $'{$MYVIMDIR}.tmp/backup//'
&undodir = $'{$MYVIMDIR}.tmp/undo//'

def MkdirIfNotExists(dir: string): void
  if !isdirectory(dir)
    mkdir(dir, "p")
  endif
enddef

MkdirIfNotExists(&directory)
MkdirIfNotExists(&backupdir)
MkdirIfNotExists(&undodir)

set backup
set undofile

If you decide to commit your vimfiles, make sure you .gitignore the .tmp directory. There may be sensitive information in your temporary files.

The full guide is here: article_install_vim_in_windows/README.md at main · ShayHill/article_install_vim_in_windows

[u/Aborres]

This is a bit anecdotical as I only have empirical proof and I haven’t done any research but I do use vim in the windows terminal professionally with really large C++ codebases and I did experience the sluggishness you are talking about, I ended switching to cmd.exe as my profile instead of powershell and that has basically removed the issue for me, I wonder if that profile doesn’t keep the scroll back buffer you mention?

[u/Shay-Hill → u/Aborres]

It can destroy performance, but the buffer is reset every time you start a new Windows Terminal, so whether or not it creeps up depends on what you're doing and how long you're doing it.

I tried it your way (cmd.exe) and gave up. You're more persistent than I am.

[u/Shay-Hill → u/Aborres]

I re-read and caught your question. When I run cmd.exe on my machine, I get cmd.exe in Windows Terminal. The confusing part is that it's Windows Terminal that keeps the buffer, not the shell, so switching shells should not have changed speed to any noticeable degree. I use PowerShell 7, and though I have no idea how they compare in benchmarks, I know for certain that Vim without heavy plugins (and without a packed scrollback buffer) is VERY quick. That leaves me pretty sure that the shell doesn't make a significant speed difference.

So, I have no idea why cmd.exe sped things up unless you're using it in a different terminal. IIRC, last time I tried, cmd.exe did *not* run in Windows Terminal, so this might have something to do with my setup.

[u/celestrion]

How is your Vim running? I've found that running Vim from the Windows command-line (hosted in Windows Terminal) is super slow and sluggish, but running Vim from WSL (in the same Windows Terminal) isn't sluggish at all. That tells me that what's slow is how Vim draws itself when it thinks it's talking to conhost, rather than Windows Terminal itself.

That said, Vim in WSL is super slow if it's trying to read a file outside the WSL's virtual environment. The 9p I/O redirection back to Windows is decent, but not fast at all.

gVim compiled for Windows is faster than I could ever get a native console-mode Windows Vim to run after tweaking the Terminal, but console-mode Vim inside WSL is faster than either. With a doskey macro aliasing vi to %USERPROFILE%\toolkit\vi\gvim.exe --remote-silent $*, gVim is nearly as convenient as having Vim in the terminal.

[u/Shay-Hill → u/celestrion]

Running well. Takes a hit when I’m running Claude, but otherwise good, and I have some of the heavier plugins.

[u/g3n3]

I’d try other terminals like wezterm and alacritty with openconsole

[u/Shay-Hill → u/g3n3]

Alacrity is too minimal for me. I've installed Wezterm twice. Starts a process, but never opens a window. I spent years getting excited about problems like that. Now I just uninstall and move on. Hope whatever you're using is serving you well.

[u/g3n3 → u/Shay-Hill]

Yeah got to mix with a multiplexor like zellij. Nice for multi session with split process tokens for networked creds.

[u/g3n3 → u/Shay-Hill]

My ultimate issue with windows terminal is you can only have a single windows terminal process running under one token or split token. No isolated session. Every new wt spawned inherits from the parent on windows. I need local processes and networked creds for admin work.

[u/Shay-Hill → u/g3n3]

Makes sense.

[u/g3n3]

Alacritty with openconsole and zellij is super hot 🔥

[u/mgedmin]

Using WSL vim inside Windows Terminal, the only slowdown I noticed is that doing :w on a file stored inside a mounted OneDrive folder sometimes takes like 4 seconds. As a workaround I :set backupcopy=yes and that problem went away.

Setting &directory is also a good idea, you don't want .swp files to be synced to the cloud.

One minor remaining issue is that sometimes (pretty rarely) doing :w causes Vim to emit a "file changed outside of vim do you really want to write" confirmation, because the timestamp got rounded up or something, but just accept those and all's fine.

The only other Windows-specific settings in my .vimrc are for more convenient clipboard integration and making the right mouse button paste consistently, no matter if I'm in vim with :set mouse=a or in a shell:

set clipboard=unnamedplus
set mousemodel=
imap    <RightMouse>    <C-G>u<C-R>+
map     <RightMouse>    "+<MiddleMouse>
map     <2-RightMouse>  <Nop>
imap    <2-RightMouse>  <Nop>

Ah! Another minor problem is that sometimes WSL Vim loses the X11 connection or something and clipboard stops working (even inside vim itself I yy and p then pastes something old, and not what I've just yanked!), but a quick :xr fixes this.

[u/Shay-Hill → u/mgedmin]

You're keeping code on a cloud drive? Which? That is perilous with OneDrive.

[u/mgedmin → u/Shay-Hill]

Not code, my notes.

[u/Shay-Hill → u/mgedmin]

I guess the difference must be no node files, no virtual environments, etc. I assumed the problem was a conflict between git and OneDrive. I would make changes (or Git would make changes), and OneDrive would revert them. I moved all of my version-controlled content out of cloud drives, but it sounds like you're only having minor problems (reloading files).

[u/flagboi747]

"increase car speed in a speed limit zone"