令和8年の僕のvimrcと起動4msの速さの理由

vimrc書いたよ!

自分としては結構うまく書けたので、よければ聞いてほしい。
一つ言っておくと、vimファーストである。
ちなみに入れてるpluginは30個程度、起動速度は4ms。

方針

• 爆速起動(vim-startuptime測定で4ms、画面更新まで13ms)
• 自動補完(ddc.vim使用)
• vimでもneovimでも動く(dpp.vim使用)
• vimrcを分割して見通しを良くする
  • Pluginリストをpresetとしてgithubからダウンロード
  • Pluginの設定と一般の設定を分ける

インストール

まずcloneです。

git clone https://github.com/uesseu/vimrc

次にvimrcにこのvimrcのを読む設定を書きます。

source [path_to_vimrc]/vimrc

次に、インストールです。起動すれば自動でインストールされます。

vim

最後に、もしうまくいかなかった時のために念のためにインストールコマンドをvimの上で叩きます。

PluginInstall

実際に採用した重要なもの

• denops
  • deno製プラグインを作れるやつ
• dpp.vim
  • プラグインマネージャを作れるやつ
• ddc
  • 自動補完プラグイン

はい、だいたい暗黒美無王のやつです。これは「設定の自由度を大きくとる」という思想があります。この思想により弄り倒す事ができました。

「つまり、使いこなせさえすれば最強」という感じです。

インストール前の設定

これ、公開するものと自分の個人設定を両方いれたかったのです。そのために、このvimrcは作り溜めた設定を別のリポジトリから取ってくる設計になっています。
インストールの順番はこのようになっています。

1. presetsの中の設定リポジトリを書いてあるtomlファイルを開く
2. 設定リポジトリをplugin_configディレクトリにクローン
3. クローンしたリポジトリに記載されているtomlファイルをdpp.vimが読む
4. dpp.vimがプラグインをインストールする
5. config内のvimscriptをscripts/config.vimにマージする

という感じなので、plugin_config、config、presetsの中のファイルを弄る事になります。

ディレクトリ内のファイル群	役割
presets/*.toml	プラグインの設定のプリセットを記載する
plugin_config/*.toml	プラグインの設定をする
config/*.vim	プラグイン以外の設定をする

vimの設定ファイルを分けたい

vimの設定ファイルは肥大していきます。とても悲しいです。肥大すれば分割すればいいのですが、分割するのもなかなか大変。そこで、本vimrcは分割した上でそれらを一つのファイルにマージして読むという方向にしました。
vimの設定モードみたいなものを作り、分割ファイルを変更したらその都度マージするようにしています。具体的にはこうです。

Vimrc personal.vim

ここではファイル群の中のpersonal.vimというファイルを弄っています。

そもそもvimの起動の速さとは何なのか

ここは大事なのですが、不明であります。詳細は下記の記事が詳しいです。

この記事では起動速度はダッシュボードの画面表示までという事になっていますが、僕はダッシュボードを使わない。しかも、perlを最後に書いたのが18年くらい前で、この記事のスクリプトの使いかたがわからなかった。

という事で、複数の方法で計測する事にしました。一つはvim-startuptime。これはvimの場合3.7ms、neovimの場合は4.0msでした。
一方、本当の起動速度については本当にわからないのですが、今回は下記の方法で測定してみました。

vim=vim
echo "Opening $1 by $vim"

run(){
  for n in {1..1000}
  do
    taskset -c 0 $vim +"e $1" +"colorscheme retrobox" +"redraw!" +"qa!"
  done
}

run2(){
  for n in {1..1000}
  do
    taskset -c 0 $vim -u NONE +"e $1" +"redraw!" +"qa!"
  done
}

if [ -e "$1" ]
  then
  time run $1
  time run2 $1
fi

これにより、

項目	vimrc	バニラ
プラグイン	あり	なし
カラースキーム	あり	なし
起動後1回画面強制更新	あり	あり

の差がわかるはずです。その条件で1000回空のシェルスクリプトを読ませて画面更新してみました。

Opening capture.sh by vim

real    0m13.956s
user    0m11.311s
sys     0m2.486s

real    0m1.818s
user    0m0.778s
sys     0m1.032s

neovimの場合

Opening capture.sh by nvim

real    0m21.575s
user    0m13.360s
sys     0m5.168s

real    0m10.346s
user    0m4.782s
sys     0m3.389s

前半がプラグインあり、後半がなしです。つまり、画面更新に消費したCPU時間を含めても14ms程度で起動しているんですね。

これって実際に画面が更新されたかどうかはわからないですよね。多分だけど、14msに画面のリフレッシュレート(60Hz)を含めると、14ms~31ms程度だと思います。つまり、ゲーミングディスプレイ(144Hz)だったら14ms~21ms程度と圧倒的に高速化するはずです。
この為だけにゲーミングディスプレイを買いそうになりましたが、我慢できました。

…褒めてほしい。

速さの理由

ある意味ここからがこの記事の本番。

前提として、コンピュータのCPUというものはとても速いです。逆にディスクやバスは遅いです。

vimスクリプトの統合

このvimrcはvim scriptを可能なかぎりマージして、ディスクの走査を減らしています。え？ssdやキャッシュの中にはいっているから遅くないだって？それでもファイルの数は多い方が遅いですよ。

dppの採用

dppは速いです。速いプラグインマネージャを使うのは基本ですね。dppもまた、vim scriptを結構一つに固めてしまいますね。カツカツに最適化されています。

プラグインの遅延ロード

dppの機能でもありますが、必須プラグイン以外は全て遅延ロードです。だって、例えばLSPが動きだすまえにある程度読む時間が必要じゃないですか。ファイルを開いて20msとかでコード書きはじめるなんてAIでも無理ですよ。
あと、chatgptさんが「VimEnterにautocmdしたら遅くなるぞ」とか言ってたけど、そんな事ないと思う。測ったからわかる。

ビルトインプラグインの遅延ロード

ビルトインプラグインも遅延ロードしています。これやっている人は多くないんじゃないかと思いますが。だいたい、netrwが起動時に必須とは思わないんですよねー。

サブプロセスの事前起動

このvimrcにはdppがはいっていますが、つまりdenoをvimで動かすためのエコシステムであるdenops依存です。というわけで、denoは事前に起動しておくほうがお得です。

viminfo/shadaの制限

vimを使う時、過去のコマンドやマークの履歴をロードします。だけど、数万前のコマンドの履歴なんか…要ります？僕はいりません。なので、そこを一寸制限しています。

CPUのコアの選択

貴方がたは、vimをソフトウェア面から高めているかもしれません。しかし、コンピュータにはソフトウェアだけでなくハードウェアもあります。ハードウェア面を用いる事により、vimの速度性能はグイッと上ります。
ここからはlinux限定であり、機種依存性が高いので公開したvimrcに入れてません。また、windows等では試していないです。でも、これは結構大事です。

intelのヘテロジニアスCPUの場合、p-coreとe-coreがあります。しかし、当然ながらvimmerにとってはvimファーストです。e-coreでvimを起動するなんてとんでもない。僕はこうします。

taskset -c 0 vim

これによって、vimの起動速度はあきらかに向上します。毎回書くのは面倒なのでbashrcにこう書きます。

alias vim='taskset -c 0 vim'
alias nvim='taskset -c 0 nvim'

しかし、これによってvimのサブプロセスの性能を1コアに制限してしまいもします。そこで、vimが起動した後でvimでサブプロセスの制限を外すコマンドを遅延起動します。

au VimEnter * silent! execute '!taskset -p -c 0-19 '.getpid()

これにより、起動にp-coreのみを用いつつサブプロセスのコア制限を外す事ができるようになります。

今の悩みは、vimにはp-coreを使ってほしいのに、サブプロセスのコア制限を外す事により、vimがe-coreに割りあてられる可能性がある事です。とても悲しい。

ぼくのかんがえたさいきょうのvimrcができた

　　　 __,.-----.,___
　　r'~:::::_,,,_:::::ヽ
　|:::r'~　　~"""''-､:::| 　　　　┌───────────────────────┐
　|;;|　,へ､　 ,.ヘ、.|::|.　　　　| vimrc なんかに　まじに　 |
r'ﾚ'　　.･ .::::::. ・ .'y^i 　　│ なっちゃって　どうするの   |
ゝ'､　　　'､___,'.　　,;'-' 　　　└────────────────────────┘
　　'､　  　----　  .,;' 　　　　　　　　　　　　　　　　　　　　　、
　 　 　';､　　　 .,;' 　　　　　　　　　　　　　　　　　　　.!~二~7
　 　  　　￣￣￣ 　　　　　　　　　　　　　　　　　　　　　　　_7^[_,i