Vimで学ぶ「適切な速度」で処理をするということについて


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について」です。というのを期待したいと思います!えっ!?