vital モジュールのロードを爆速にする & ロード方法を考える

[haya14busa]

概要

• https://github.com/haya14busa/revital.vim のコードを改善しながらvital.vimに移植しました
  • ref: revital.vim で vital.vim を爆速にしてお前らの Vim plugin を速くする - haya14busa
• ついでにいい機会なので vital のモジュールのロードの仕方を考えましょう autoload/vital.vimが更新された時の対応を決めたい #40 autoload/vital.vimに関する新しい仕組みの提案 #41
• あと :Vitalize とか s:V.import()(新しいほう) のテストもしています

使い方

1. :Vitalize . でアップデートしたり新たに :Vitalize
2. vital#of({plugin-name}) の変わりに vital#{plugin-name}#of() を使う

これだけ!
ただ，vital#of({plugin-name})でも速くなるようにしています． except vital#of('vital')

現時点で既に対応しているプラグイン

• https://github.com/haya14busa/incsearch.vim
• https://github.com/easymotion/vim-easymotion

ベンチマーク

TODO

注意点

• vital#of('vital') と プラグイン内に外部モジュールを同梱したい #137 の外部モジュールを同梱する機能 (個人的にself moduleとよんでいる) は速くなりません．

vital#of をどうするか?

1. vital#of({plugin-name}) はそのままで，速くしたい場合は vital#{plugin-name}#of()を導入
2. vital#of({plugin-name}) のインターフェースはそのままで内部で早くする．vital#{plugin-name}#of()は導入しない
3. vital#of({plugin-name}) のインターフェースはそのままで内部で早くする．vital#{plugin-name}#of()も導入する
4. vital#of({plugin-name}) は組み込まず vital#{plugin-name}#of()に完全移行
   • 厳密にはvital#of('vital')相当は残す or 別の対応する機構を提供
5. そもそもvitalのローダ作る必要なくね? vital#{plugin-name}#import({module-name}) とかに移行する．

などなどがあります

あと少なくとも新しいvitalオブジェクトでは s:V.search(), s:V.load(), s:V.exists() とか別にいらないんじゃないかと思うみたいな思いもあります

疲れたのであとは随時追記するかコメントします

[haya14busa]

twitterの議論 https://twitter.com/_tyru_/status/713040372415344640
cc @tyru @rhysd @thinca

[tyru]

関連 #40 #41

[rhysd]

関連記事：

http://haya14busa.com/revital-vim-makes-vital-vim-a-lot-faster/

速くなるのは間違いないと思うので入れる方向で行きたいです．

[haya14busa]

冒頭コメントちょっとアップデートした．

[haya14busa]

このへんに記事に対しての thinca さんのコメント http://lingr.com/room/vim/archives/2016/03/23#message-23153686

[haya14busa]

revital で落ちてなかったのに落ちてるのはナンデや(古いvim)..．まぁまた対応します

[thinca]

インストールされる各モジュールを書き換えることは、モジュールの製作者が予期しない副作用が発生する可能性があるので消極的です。(絶対ダメとは言っていない)

[haya14busa]

はい，まぁそれがわかってるから最初は別リポジトリにしたんですが流れ的に行けるかなと(流れ力)

[haya14busa]

s:___vital_function___ 以外はスクリプト変数も関数も汚してないですが，まぁ逆に言うとひとつは汚してはいる

[haya14busa]

thincaさんが前に言っていたようなsidのみ返す関数にしても同様にスクリプト変数1つ，またはスクリプト関数１つ定義しなきゃだめですね

[thinca]

あーあと使用するローダーを :Vitalize のオプションで指定できるようにして、新版は明示的に指定した時のみ使うようにすると良いかも。移行期間的な。gcc の -std=c++14 的な感じで(ちょっと違うけど)。
ただめっちゃ面倒そうなので、どうしても面倒ならそれもやむなし。

[haya14busa]

選択はたしかに有りな気はしますね

[haya14busa]

s:___vital_function___ 以外はスクリプト変数も関数も汚してないですが，まぁ逆に言うとひとつは汚してはいる

これ 7.3.1170 以降は消せるので，:Vitalize 時にプラグインが7.3.1170以前に対応するかどうか決めれるみたいなのはやるといいかも

[haya14busa]

これ 7.3.1170 以降は消せるので，:Vitalize 時にプラグインが7.3.1170以前に対応するかどうか決めれるみたいなのはやるといいかも

冷静に考えると :Vitalizer で指定とかなしで対応できるな

[haya14busa]

execute 使うけどスクリプト変数もスクリプト関数も残さないようにした．便利．
テストの落ち方が謎でつらい

[ujihisa]

APIについて (実装は無視):

これまでvital#of("aaa")みたいにof()という関数を提供してたのはconstructor fuctoryとしてほとんど無名にしたかったための命名でした。今回vital#aaa#of()みたいにユーザプラギン名が文字列でない形ででてくるなら、実装が可能ならofすらとってしまってvital#aaa()みたいにするとより便利さ。(実装上うまく安全に混ぜることができないならスルー力で)

[rhysd]

vital#aaa だとファイルをプラギンごとに分けられないと思います．ただ，確かに vital#plugin#of は微妙ですね…

[haya14busa]

vital#pluginname() は無理ですね．

ただ，確かに vital#plugin#of は微妙ですね…

vital#pluginname() は無理となったら結局 vital#pluginname#{無名にちかいconstruct関数名} にしなきゃだめで vital#of() の議論と同じになるのではないでしょうか?

インターフェース追加して vital#pluginname#import() とかはありかなとかは考えてますが, vital#of()相当は残したほうが移行もスムーズにできるし便利そう．

[haya14busa]

はい．あってます．appveyor の vim7.3 build でヨクワカラナイエラーが出ることを本当は修正したい...原因究明したい...という以外は何もやることは残ってないはずです．

ただテスト通っているのは別のテストをスキップしてたので対象の vital.vimspec をスキップするように修正しました．

[haya14busa]

厳密にこのPRのheadではなくなってる気もするけど, incsearch.vimやeasymotoinでは前からこのPRをmasterで試していて，今の所おかしくなったというissueはないです．

[Shougo]

unite.vim, neocomplete 等で使用していますが、特に問題はないです。

[ujihisa]

マージ & ブログ記事たのしみです!

[tyru]

Windows on Vim 7.3 で動かない件は Changes に書いておく必要はありそうですね。
ただもう Vim 7.3 を使う人も少なくなってきてるような気はするので、思った程問題ないような気もします。

• Vim プラグイン開発者に求めること：Windows on Vim 7.3 では現状動かない事を理解した上で vital を使ってもらう
• このPRで行うこと (Windows on Vim 7.3 で動かない件に対して)
  • known issue としてdocに書く (tyru が別PRでやる)
  • doc の vital#of('vital') を vital#{plugin-name}#of('vital') に変更 (tyru が別PRでやる)
  • Issue 作成 🎫 [AppVeyor] Sometimes buffer overrun error occurs when running tests #426
  • マージ 🎉

自分はこの件に関してこれで十分と感じてるんですが、皆さんはどうでしょうか？

[haya14busa]

Windows on Vim 7.3 で動かない件は Changes に書いておく必要はありそうですね。
ただもう Vim 7.3 を使う人も少なくなってきてるような気はするので、思った程問題ないような気もします。

実はそれよりももっと条件は狭まっていて，

1. すくなくとも起こるとしても :Vitalize時関連．(またはテスト)
2. 他のテスト(System.Process.Vimproc)をskipしたりすると通ることから，普通に:Vitalizeする分にはVim 7.3 on Windowsだろうが動く
3. このPRでバグが入ったわけではなく，そもそもmasterのvitalでもテストのみ移植すると再現する

という感じです．

なので Changes に書くようなことではないかな．
丁寧にやるなら issue 作成プラスknown issue としてdocに書くくらいでしょうか．

[haya14busa]

なので

Vim プラグイン開発者に求めること：Windows on Vim 7.3 では現状動かない事を理解した上で vital を使ってもらう

これは言い過ぎで，Windows on Vim 7.3 で:Vitalizeする際に特定の条件で失敗する可能性がある．というだけなはずです．
プラグインを使うユーザに関しては関係ないはず．

[tyru]

あー vitalizer の話だったんですね。それじゃ Changes に書かなくても良さそうですね。

[haya14busa]

コメントアウトのこってたので後で消します

[tyru]

あとこのタスクもありました (上のタスクリスト更新)。

さすがに既存のhelpのvital#of('vital')修正して回る作業をここでするとdiffが死ぬので別で

上ではドキュメントの修正もタスクとして上げちゃいましたが、こういったドキュメントの修正であれば自分がGWに別PRでやるので、 @haya14busa さんがもう修正の予定がないならマージしても良いと自分は思います。

[thinca]

@haya14busa マージしちゃっても良いかな?

[haya14busa]

👍👍👍👍👍

[haya14busa]

vital#of() -> vital#vital#of のドキュメント修正は単にdiff増やしたくなかっただけで grep からの qfreplaceで多分しゅっと直せるけど，やっていただけるなら任せちゃおうかな?

あと，test で呼ばれてる vital#of() も vital#vital#of() にかえれそう

[haya14busa]

ﾏｯｼﾞありがとうございますっ ✨ ✨ ✨