Vimで学ぶ「適切な速度」で処理をするということについて
この記事は atWare Advent Calendar 2015 の2日目の記事です。
昨年はボードゲームでリアルなコミュニケーションというタイトルでモノポリーについて記事を書きましたが、今年はモノポリーかVimのどちらの記事を書くか苦渋の末に迷ってVimをお題にしたので、イメージだけはモノポリーにしてみました。
今日書くエントリーは適切な速度で処理をするということをVimをとおして学んでみたいと思います。
Vimとは
一般的にVi互換で機能拡張が入ったエディタという事でプログラマやサーバー管理者などに普及しています。
弊社内の統計値によると72%の社員が今年になってこのエディタを使った事があるそうです。
このエディタの特徴として起動が速い事で一般的に知られています。もう少し突っ込んだ話しをするとVimというよりViが軽くてどこのサーバーにでもインストールされているということでしょうか。
さらにいうと、一般的なLinuxOSですとviコマンドがVimコマンドのvi compatibleモードのエイリアスとなっている事はわりと弊社社内をはじめVimを使った事ある人には知れ渡ってきていることですね。
さて、viコマンドの起動はなぜ速いのでしょうか？理由は結構わかりやすく、C言語で書かれてていることに加え、数十年速度や機能改善をされ続けた成熟したプログラムというのに加え、もう一つ大きな理由として余分な機能を読みこまず、起動しているという事です。
Vimの魅力としてカスタマイズできることにあります。VimはVim scriptというVim専用のスクリプト言語で機能拡張を行う事ができるのですが、デフォルトのVimではいくつかのデフォルトプラグインを読み込み起動しています。
ディストリビューションやカスタマイズビルド（例えばMacVimやKaoriyaパッチVimなど）版のVimによって違いはありますが、例えば
$ ls /usr/share/vim/vim73/plugin/
README.txt netrwPlugin.vim tohtml.vim
getscriptPlugin.vim rrhelper.vim vimballPlugin.vim
gzip.vim spellfile.vim zipPlugin.vim
matchparen.vim tarPlugin.vim
私の環境のVimにはこんなプラグインがインストールされていました。
gzip.vimはvimでzipファイルを開いた時に展開せずにVimでアーカイブ内のファイルを閲覧・編集できるというプラグインです。viコマンドではこのcompatibleモードで起動するのでこのプラグインは読み込まれませんが、vimコマンドで起動すれば読み込まれてから起動します。
こういうデフォルトプラグイン数個なら体感的に差はありませんが、便利なプラグインがGitHubやvim.orgで公開されており、自分のスタイルに合った便利な機能を追加しようとプラグインをどんどん増やしていくと体感できるほどに遅くなる事があります。これは、Vimに限った事ではなく他のエディタでもよくあることですね。
ただ遅いだけではない
いよいよ本題に入っていきます。みなさんパフォーマンスチューニングの時に測定していますか？
今の時代なら感覚に頼らずメトリクスや速度測定をして数値に基づいてチューニングしていくのが一般的ですよね。
一般的な手法を用いて遅さを実感してみたいと思います。
VimはC言語で書かれてコンパイルされて実行されていますが、機能拡張は基本的にはVim sciprtという言語で動的に実されます。
まずは、Vimをプラグイン読み込みせず、compatibleモードかつvimの設定ファイルも読み込まずに起動速度を測定できるオプションもつけて起動してみましょう。
$vim -u NONE --noplugin --startuptime vim-startup.log
そうするとこんな結果になりました。
$cat vim-startup.log
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.010 000.010: --- VIM STARTING ---
000.093 000.083: Allocated generic buffers
000.106 000.013: GUI prepared
000.494 000.388: locale set
000.500 000.006: clipboard setup
000.507 000.007: window checked
001.124 000.617: inits 1
001.137 000.013: parsing arguments
001.523 000.386: expanding arguments
005.239 003.716: shell init
005.492 000.253: Termcap init
005.535 000.043: inits 2
007.877 002.342: init highlight
007.880 000.003: sourcing vimrc file(s)
007.890 000.010: inits 3
007.910 000.020: setting raw mode
007.928 000.018: start termcap
007.950 000.022: clearing screen
008.044 000.094: opening buffers
008.047 000.003: BufEnter autocommands
008.051 000.004: editing files in windows
008.073 000.022: VimEnter autocommands
008.080 000.007: before starting main loop
008.681 000.601: first screen update
008.684 000.003: --- VIM STARTED ---
8msで起動できました。
VimScriptを読み込んで起動
こんな簡単な再帰呼び出しを行うシンプルなVim scriptを書きました。
$cat recursive.vim
"set maxfuncdepth=100
function! s:Recursive(count)
"echo a:count
if a:count > 1
call s:Recursive(a:count - 1)
endif
endfunction
call s:Recursive(1)
先ほどと同じ容量でVim scriptを読み込んで起動してみます。
$vim -S recursive.vim -u NONE --noplugin --startuptime vim-startup.log
結果を表示してみましょう。
$cat vim-startup.log
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.006 000.006: --- VIM STARTING ---
000.077 000.071: Allocated generic buffers
000.088 000.011: GUI prepared
000.416 000.328: locale set
000.421 000.005: clipboard setup
000.427 000.006: window checked
001.019 000.592: inits 1
001.034 000.015: parsing arguments
001.421 000.387: expanding arguments
005.263 003.842: shell init
005.522 000.259: Termcap init
005.567 000.045: inits 2
007.934 002.367: init highlight
007.937 000.003: sourcing vimrc file(s)
007.947 000.010: inits 3
007.968 000.021: setting raw mode
007.985 000.017: start termcap
008.007 000.022: clearing screen
008.100 000.093: opening buffers
008.103 000.003: BufEnter autocommands
008.107 000.004: editing files in windows
008.332 000.080 000.080: sourcing recursive.vim
008.345 000.158: executing command arguments
008.346 000.001: VimEnter autocommands
008.351 000.005: before starting main loop
009.246 000.895: first screen update
009.248 000.002: --- VIM STARTED ---
なっ、なんと先ほど8msだった起動速度が9msになってしまいました。
1msも起動速度が遅くなってしまったらこれは非常に困ってしまいますね。
生産性が悪くなって仕方なくなるかもしれません。少し大げさでした...
Vim scriptの関数呼び出しを増やしてみる
先ほどは関数呼び出し1回だけだったものを100回の再帰呼び出しに変えてみます。
関数内では処理はないに等しいのでほぼ関数呼び出しだけのコストになります。
結果は下記の通り。
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.008 000.008: --- VIM STARTING ---
000.090 000.082: Allocated generic buffers
000.103 000.013: GUI prepared
000.498 000.395: locale set
000.504 000.006: clipboard setup
000.511 000.007: window checked
001.193 000.682: inits 1
001.212 000.019: parsing arguments
001.740 000.528: expanding arguments
005.770 004.030: shell init
006.042 000.272: Termcap init
006.088 000.046: inits 2
008.466 002.378: init highlight
008.469 000.003: sourcing vimrc file(s)
008.479 000.010: inits 3
008.500 000.021: setting raw mode
008.518 000.018: start termcap
008.545 000.027: clearing screen
008.642 000.097: opening buffers
008.646 000.004: BufEnter autocommands
008.650 000.004: editing files in windows
010.080 001.279 001.279: sourcing recursive.vim
010.098 000.169: executing command arguments
010.100 000.002: VimEnter autocommands
010.105 000.005: before starting main loop
010.635 000.530: first screen update
010.638 000.003: --- VIM STARTED ---
先ほどは、9msで終わったところが10ms後半になってしまいました。
着目したいところがあるのでピックアップしてみたいと思います。
008.332 000.080 000.080: sourcing recursive.vim
010.080 001.279 001.279: sourcing recursive.vim
1回の関数呼び出しの際に80µsecだったところが、15倍ほど時間がかかっていますね。
関数呼び出し1つで数十µsecは遅いと感じましたか？速いと感じましたか？
あなたの普段使っている言語。例えばJavaやPythonやRubyやGoではどれくらいのコストでしょうか？
非機能要件でシステムのレスポンス要求のオーダーはどれくらいに設定していますか？
秒単位の事もあれば、msec単位のこともあります。これがレイテンシも含め数十msecで処理したいシステムなら致命的な程遅いのです。また、チリも積もればなんとやらでプラグインの用途によってはUIが体感的に遅いと感じてしまう事もあります。
そういう時にどういうアプローチがとれるでしょうか？
アプローチ
一般的なWebアプリと同じような発想のアプローチをとることができます。
Rubyでも速度を担保したい場合にnativeにコンパイルしたモジュールを部分的に利用することがありますね。同じようにVimからもネイティブなモジュールを呼び出す事ができます。
他にもVimではPythonやLuaのインターフェースを使うということもできますので、Vim script以外の言語を利用するというアプローチもありですね。
アプリケーションを丸ごと置き換えるのではなく部分最適というものです。
「適切な速度」で処理をするということについて
とは言ったものの、富豪的にリソースを扱える時代でもシビアにならないといけない時とそうでない時の差はやはり存在します。
Vimを例に出しましたが何ごとも適材適所で、実装でひたすらがんばるというのもやり方の一つですし、部分的なネイティブで部分的に最適化もいいでしょう。また、MessagePackやZeroMQのようものを使い、プロトコルを決めてロスを最小限にし効率良く処理するという、分割して粗結合にする方法もありかもしれません。
適切な速度を言語レベルで担保しようとするのか、システム全体で担保しようとするのか、それだけでも視点は違ってきます。
大きな視点で考えた場合には影響範囲は留まる所をしれませんね！！
非機能要件で必要な速度を担保しつつ、クラウドリソースを活用したうえでアーキテクチャ次第で色んなアプローチがとれるので、そこを考えていくのは本当に面白いです。
まとめ
本記事は@kamichiduさんの発表にインスパイアを受け書きました。
興味深い面白い発表してくださりそして発表後の小話にもつきあって頂きました。この場を借りて感謝の言葉をお伝えしたいです。ありがとうございます。
自分なりに普段の業務を通じて感じていた所がVimを通してあらためて気づけたというのは非常に面白かったです。なお、このエントリーはVim Advent Calendar 2015を兼ねません。
明日はYanouさんによる「IntelliJについて」です。というのを期待したいと思います！えっ！？
