100% cpu usage

[brandonbloom]

This is effectively re-opening #685. I'm experiencing the same problem.

Latest unite, macvim, and vimproc. Occurs after using file_rec/async at least once. Shortly after closing the unite window, vim becomes completely unresponsive for 5 to 10 seconds. Activity monitory shows 100% CPU usage.

Only seems to be a problem for very large trees (mine has about 17,000 files). Smaller trees work great.

[wedens]

+1. i have the same issue again (after update)

[Shougo]

It is Vim's garbage collection problem.
I cannot fix it.
This is patch for it.

vim-jp/issues#608 (Japanese thread)

[h-east]

Sorry in Japanese.

@Shougo これ、Vim本体のGC問題だと断定した根拠は何ですか？ちゃんと検証したの？
ここ2週間で同様の問題が2件発生(#685, #701)しているようだけど、今までこういう報告なかったの？
unite.vimに不具合がある可能性はないの？
そりゃ他人の環境で起きている問題を自分の環境で再現し難い類いの問題だというのは分かるけど、思い込みや願望だけで発言していないかい？
ちゃんと問題の切り分けしようぜ！

[Shougo]

Sorry in Japanese, too.

これ、Vim本体のGC問題だと断定した根拠は何ですか？ちゃんと検証したの？

はい。これは unite.vim 開発直後からある極めて既知の問題だからです。
GC が原因であることもだいぶ前からわかっていました。

ここ2週間で同様の問題が2件発生(#685, #701)しているようだけど、今までこういう報告なかったの？

報告をしていないだけで、困っている報告は以前からあったのではないかと思います。
unite.vimを巨大なディレクトリで使っていれば誰でも気づく問題です。

unite.vimに不具合がある可能性はないの？

これはありません。GCの問題をunite.vimの本体で対処しようともしましたが、挫折しました。

そりゃ他人の環境で起きている問題を自分の環境で再現し難い類いの問題だというのは分かるけど、思い込みや願望だけで発言していないかい？

確かに私の以前の検証が不十分であったことは否めません。
しかし、この問題に関しては、手元で既に再現している既知の問題なので即答したのです。

[Shougo]

これ、Vim本体のGC問題だと断定した根拠は何ですか？ちゃんと検証したの？

とりあえず、根拠は
「CPU使用率100%が10秒続く」という点と「巨大なディレクトリのみで起こる問題」だという点です。
これは Vim の GC で固まっている時特有の症状です。
unite.vimのバグの場合は普通無限ループで固まるかエラーで止まるので、10秒たってから復活するというのはありえません。

[h-east]

@Shougo 根拠示せてないね。ずーっと maybe/wannabe ですやん。
何でバグを追い詰めないの？

とりあえず、根拠は
「CPU使用率100%が10秒続く」という点と「巨大なディレクトリのみで起こる問題」だという点です。
これは Vim の GC で固まっている時特有の症状です。
unite.vimのバグの場合は普通無限ループで固まるかエラーで止まるので、10秒たってから復活するというのはありえません。

それらは根拠にならないよ。
Vim組み込み関数に変なパラメータ渡したらすごく時間掛かることだってあるでしょう。

もう1回言う。
何でバグを追い詰めないの？

#685, #701の報告はtodeskingさんのpatchがある今は絶好の検証チャンスでしょ。
まず報告者に「Please Do not remove your cache.」ってお願いして、todeskingさんのpatchを試して貰えばハッキリするんじゃないの？
「Yeah! 10秒フリーズが500msecに短縮されたよ！」とか「いや何も改善されなかったよ」とかの反応で「あーやっぱりVim本体のGCが原因だったね」か「うむむ！？」等いろいろ次のアクションが明確になってくると思うんだ。

この辺の所はvim-jp/Issues のパッチ職人の言動みてたらかなり勉強になると思う。頑張れ。

[Shougo]

了解しました。こちらでtodeskingさんのパッチを使って確かめました。
問題は改善しています。
よって、これはGarbage collectの問題だと思います。

@brandonbloom Please use this patch for your vim.

https://gist.github.com/0c58a7398c63ab4c3066

[h-east]

@Shougo

問題は改善しています。

なにがどうなったかさっぱり分からん。Evidence Please!
せめてさぁ、「これこれこういう状態の環境(OS, Vim ver., ...)でこういう現象が発生していたけど例のpatchを当てたらxx秒がoo秒に改善されました」とかの形式で頼むわ。

よって、これはGarbage collectの問題だと思います。

人を納得させる気ないよね。

[Shougo]

最小 .vimrc

set nocompatible

set rtp+=~/work/unite.vim
set rtp+=~/work/vimproc.vim

" Required:
filetype plugin indent on

let g:unite_source_rec_max_cache_files = 0

環境：Ubuntu 14.04, Vim 7.4.415

これは環境に依存します。私の場合、ホームディレクトリ以下の 10万ファイルのリストを生成させて確認しました。

再現手順：

1. vim -u test.vimrc -U NONE -i NONE
2. :Unite file_rec/async:/home/shougo
3. q でバッファを閉じる
4. :Unite file_rec/async:/home/shougo

garbage_collect()の仕様上、手順が自動化できず正確な時間を測定することはできませんでした。

パッチ前：手順3の段階でVimが5分以上フリーズするため測定不能
パッチ後：手順3.のときフリーズしない（一瞬）。手順4.にてuniteバッファを開くのに7秒程度かかる

これでよろしいでしょうか。

[h-east]

@Shougo 👍 LGTM --> vim-jp/issues#608

[Shougo]

Thanks.

[luishdez]

I have the same problem, I confirm that it's a vim problem. I've forked the repo and apply the patch and I confirm that works and no longer gets 100% of CPU using Unite

Fork with patch: https://github.com/luishdez/vim I've tested this in OS X, ( best way is to brew edit vim ) and set the zip URL and the sha1

[Shougo]

Fixed in Vim 7.4.615

https://groups.google.com/forum/#!topic/vim_dev/pXjj7rww5RY