Ctags: 並列ctags

こんにちは、

組み込みの並列実装は興味深いものですが、異なるディレクトリで異なるctagsを起動し、生成されたファイルをマージすることで、大きなコードベースの更新を並列化することはすでに可能です（これは、1つを除くすべてのファイルから！で始まる行を削除するだけで実行できます。その後、すべてのファイルでsort --mergeを使用します）。

ただし、最新のマシンはI / Oバウンドであると予想されるため、並列化されたctagsからスピードアップが得られるとは確信していません。 ただし、それを確認するためにプロファイルを作成する必要があります。

@mawww https://github.com/ggreer/the_silver_searcherは同意しないと確信してい

複数のctagsを実行すると、標準のemacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180-L183から調整するのが非常に困難になり

@mawww https://github.com/ggreer/the_silver_searcherは同意しないと確信してい

いい視点ね。

複数のctagsを実行すると、標準のemacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180-L183から調整するのが非常に困難になり

シェルスクリプトラッパーはすでに長い道のりを進んでいる可能性がありますが、それを直接ctagsに統合する方が効率的かもしれません。

@fommilこの問題に関するその人のたのかはあまり明確ではありません（まあ、行間で読むことができますが、まあ）、とにかくそれは実際にはそれほど多くありません。 そして、私は彼の仕事を無視するつもりはありませんが、マルチスレッドについて学んだばかりの人の結果を完全に信頼するつもりはありません（特に、ミューテックスの誤用がMTのパフォーマンスをどれだけ破壊するかという理由で） 。 彼が完全に正しいとは言えませんが、私は確信する必要があります:)
また、彼自身のテストで、彼のマシンでは、並列化をまったく行わない場合よりも多くのワーカースレッドがすぐに悪化することがわかったことに注意してください。 かわいらしいですが、処理するハードウェア、OS、データに大きく依存する可能性が高いため、「テストではNスレッドを使用した方がパフォーマンスが優れているようです」よりも賢明なはずです。

また、あまり魅力的ではないもう一つの理由は、それが私たちにそれほど多くを与えるとは思わないだけでなく、エラーが発生しやすい大量の作業になるからです。 現在、CTagsコードベースは、スレッドを解析する並列タグをサポートするための形ではまったくありません。 比較的簡単に分割できるのは、init /ディレクトリトラバーサルと_onesingle_パーサースレッドだけです。
そして最後に、コードベースのあらゆる場所（特にパーサー）で実行するためのより賢明な最適化があると確信しています。

確かに、マルチスレッドは、非常にうまく使用すれば、おそらく_ある程度の_利点がありますが、最も興味深い改善ではない可能性があります。

また、それがあまり魅力的でないもう1つの理由は、[…]エラーが発生しやすい大量の作業になるためです。 現在、CTagsコードベースは、スレッドを解析する並列タグをサポートするための形ではまったくありません。 比較的簡単に分割できるのは、init /ディレクトリトラバーサルと_onesingle_パーサースレッドだけです。

ところで、私はコードのこの領域を改善することが良い考えではないという意味ではありません、私はそうだと思います（特に将来のlibctagsの可能性のために）。 つまり、パフォーマンスが目標である場合、それはおそらく（現在）努力する価値がなく、焦点を当てるべきより重要な領域があるということです。

ところで、プロファイラーを起動し、膨大な数のデータを膨大な数の方法でプロファイリングすることは、おそらく興味深いことです。

GNUパラレルはあなたを助けるかもしれません。

前に述べたよう

I / Oがキャッシュからのものである場合、パーサーの並列実行により、処理速度が大幅に向上する可能性があります（これは、エディターからディレクトリでctagsを実行するN回目の場合がよくあります）。

@pragmaware IMO、ライブラリはフォークしないでください。

日本語のテキストを読む場合は、 https：//qiita.com/dalance/items/c76141a097e25fabefe8の記事を
（このコメントを書いた後、ptagsのgitリポジトリ（https://github.com/dalance/ptags）を見つけました。ページは英語で書かれています。）

作者が開発したptagsという名前のツールを報告します。 ツールはRustで書かれており、ctagsをラップします。
入力のセットに対してctagsを並列に実行します。
私はその内部を略奪しません。 ただし、明らかに複数のctagsプロセスを実行しています。

結果は非常に印象的です。 単一処理の5倍の速度です。 CPUの数は書かれていません。 メモリのサイズは十分かもしれません（= 128GB）。 作成者は、同じ入力セットに対して10回のptagを実行して、ページキャッシュをホットにします。

これらのことはptagsのようなラッパーで行う必要がありますが、この素晴らしい結果を無視することは困難です。
私はすぐにハッキングしました。 https://github.com/masatake/ctags/tree/parallel
新しく導入されたオプション--_ parallelは、_parallelで複数のctagsプロセスを実行します。

ワーカープロセスの数8は、ハードコーディングされています。 私のノートPCには8つのコアがあります。
MEMORYは32GBです。 ターゲット入力は、最新のLinuxカーネルソースツリーです。
私の.ctagsは十分に毛深いです。

結果はほとんど同じです：2〜3倍速くなります。

[yamato@master]~/var/ctags-github% cat run.sh
cat run.sh
for i in $(seq 1 5); do
    echo "#"
    echo "# TRAIL #$i"
    echo "#"
    echo "# parallel 8"
    time  ./ctags    --_parallel -R  ~/var/linux > /dev/null
    echo "# single"
    time  ./ctags -o - --sort=no -R  ~/var/linux > /dev/null
done
[yamato@master]~/var/ctags-github% bash run.sh 
bash run.sh 
#
# TRAIL #1
#
# parallel 8

real    0m29.073s
user    3m5.791s
sys 0m32.347s
# single

real    1m21.397s
user    1m14.601s
sys 0m6.521s
#
# TRAIL #2
#
# parallel 8

real    0m29.746s
user    3m4.601s
sys 0m32.175s
# single

real    1m26.660s
user    1m19.176s
sys 0m7.191s
#
# TRAIL #3
#
# parallel 8

real    0m28.290s
user    3m2.524s
sys 0m31.081s
# single

real    1m21.927s
user    1m14.775s
sys 0m6.896s
#
# TRAIL #4
#
# parallel 8

real    0m28.644s
user    3m3.839s
sys 0m31.756s
# single

real    1m13.319s
user    1m7.294s
sys 0m5.843s
#
# TRAIL #5
#
# parallel 8

real    0m29.274s
user    3m9.387s
sys 0m32.363s
# single

real    1m13.621s
user    1m7.487s
sys 0m5.941s
[yamato@master]~/var/ctags-github% 

（両方のタグファイルをコピーしました。違いはありません。）

満足にはほど遠いですが、始めるには良い場所です。

労働者のアウトプットを集めなければならないのかしら。

こんにちは@masatake私は作業する予定のないすべてのオープンチケットを

今後もこのアイテムに取り組んでいきます。 ここでの議論の記録は私にとって貴重なものになるので、このアイテムを開いたままにしておきたいと思います。

@masatakeは、新しいチケットからこのチケットにリンクして、完全な履歴を保持することができます。 新しい仕事のために[問題]タブをクリーンアップしようとしているので、これは本当に役に立ちます。このチケットのような雑然としたものが邪魔にならないようにします。

@fommil 、ユニバーサルCtagsの背後にある原動力である@masatakeを、コミット数0に対して2,700コミットでオーバーライドする方法がわかりません。 バグ（またはGitHubの用語では「問題」）を開くと、このバグはプロジェクトの所有物になります。 私はあなたがそれを見ることをやめ、それについての電子メールを受け取らないことができると信じています。

再開。

@ dtikhonov @ masatakeこのチケットを閉じてください。 https://github.com/issuesビューで、私の作業に関係のない唯一のチケットです。

チケットを閉じない限り、このビューからチケットを削除することはできません。 退会しても。

確かに、私がチケットを作成したときにリポジトリの所有者がこのコントロールを持っていることを私は知りませんでした。そうでなければ、私はそうしなかったでしょう。

これに取り組みたい場合は、新しいチケットを作成してこのチケットを参照してください。すべてのディスカッションが保持されます。 または、 https： //github.com/universal-ctags/ctags/issues/761#issuecomment-373720839の内容をコピーして新しいチケットに貼り付け

これは私が尋ねるほど多くはないと思います。

コピー＆ペーストのためだけに一時的なGitHubアカウントを作成できますか？
したがって、自分でコピー＆ペーストを行うことができます。
その後、アカウントを削除できます。

確かに、それがこれを修正する唯一の方法である場合、私はそれを行うことができます。

終わり！ このチケットを閉じさせてくれてありがとう。 TODOタスクが大幅にクリーンアップされます。