Ctags: parallele ctags

Hallo,

während die eingebaute parallele Implementierung interessant sein kann, ist es bereits möglich, die Aktualisierung einer großen Codebasis zu parallelisieren, indem verschiedene Ctags in verschiedenen Verzeichnissen gestartet und dann die generierten Dateien zusammengeführt werden (was einfach durch das Löschen der Zeilen beginnend mit ! aus allen Dateien außer einer und erfolgen kann Verwenden von sort --merge für alle Dateien danach).

Ich bin jedoch nicht davon überzeugt, dass Sie durch parallelisierte Ctags eine Beschleunigung erhalten, da ich erwarte, dass moderne Maschinen E/A-gebunden sind. Das müsste jedoch profiliert werden, um sicherzugehen.

@mawww Ich bin mir sicher, dass https://github.com/ggreer/the_silver_searcher anderer Meinung wäre :wink:

Das Ausführen mehrerer Ctags wäre extrem schwierig von den Standard-Emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183 . zu koordinieren

@mawww Ich bin mir sicher, dass https://github.com/ggreer/the_silver_searcher anderer Meinung wäre :wink:

Guter Punkt.

Das Ausführen mehrerer Ctags wäre extrem schwierig von den Standard-Emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183 . zu koordinieren

Ein Shell-Skript-Wrapper könnte schon viel bewirken, aber ja, es könnte effizienter sein, das direkt in Ctags zu integrieren.

@fommil Der Blogpost dieses Typen zu diesem Thema ist nicht ganz klar, von wo es angefangen hat bis wohin es ging ( naja , man kann es zwischen den Zeilen lesen, aber gut), und sowieso ist es wirklich nicht so viel. Und ich möchte keine seiner Arbeiten außer Acht lassen, aber ich werde den Ergebnissen von jemandem nicht völlig vertrauen, der scheinbar gerade erst etwas über Multithreading gelernt hat (insbesondere, weil zB ein missbrauchter Mutex jede Leistung zerstört, die MT bieten kann). . Ich sage nicht, dass er nicht ganz recht hat, aber ich muss überzeugt werden :)
Und beachten Sie, wie seine eigenen Tests zeigten, dass auf seinen Maschinen zu viele Worker-Threads schnell schlimmer wurden als eine überhaupt keine Parallelisierung. Es ist süß, hängt aber wahrscheinlich stark von der Hardware, dem Betriebssystem und den zu verarbeitenden Daten ab, daher sollte es wahrscheinlich sinnvoller sein als "Nun, die Verwendung von N Threads schien in meinen Tests besser abzuschneiden".

Ein weiterer Grund, warum es mich nicht so anspricht, ist, dass es uns nicht nur nicht so viel bringen wird, sondern dass es auch eine Menge fehleranfälliger Arbeit sein wird. Derzeit ist die Codebasis von CTags absolut nicht in der Lage, parallele Tag-Parsing-Threads zu unterstützen. Alles, was Sie _relativ leicht_ aufteilen können, ist die Init/Verzeichnis-Durchquerung und _ein einzelner_ Parser-Thread.
Und schließlich bin ich zuversichtlich, dass wir überall in der Codebasis (und insbesondere in den Parsern) sinnvollere Optimierungen durchführen müssen.

Sicher, Multithreading _kann_ wahrscheinlich _einige_ Vorteile haben, wenn es sehr gut eingesetzt wird, aber es ist wahrscheinlich nicht die interessanteste Verbesserung.

Ein weiterer Grund, warum es mich nicht so anspricht, ist, dass es […] eine große Menge an fehleranfälliger Arbeit sein wird. Derzeit ist die Codebasis von CTags absolut nicht in der Lage, parallele Tag-Parsing-Threads zu unterstützen. Alles, was Sie _relativ leicht_ aufteilen können, ist die Init/Verzeichnis-Durchquerung und _ein einzelner_ Parser-Thread.

Übrigens, ich meine nicht, dass es keine gute Idee ist, diesen Bereich im Code zu verbessern, ich denke, es ist (insbesondere für mögliche zukünftige libctags). Ich meine nur, wenn Leistung das Ziel ist, lohnt es sich wahrscheinlich (derzeit) nicht, und es gibt wichtigere Bereiche, auf die man sich konzentrieren sollte.

Übrigens, es wäre wahrscheinlich interessant, einen Profiler zu starten und eine Unmenge von Daten auf unzählige Arten zu profilieren.

GNU parallel kann Ihnen helfen.

Wie bereits erwähnt vor , kann die Optimierung Lesung bis ctags einiges beschleunigen.

Die parallele Ausführung von Parsern könnte die Dinge ziemlich beschleunigen, wenn I/O aus dem Cache kommt (und dies ist oft der Fall, wenn Sie ctags in einem Verzeichnis von einem Editor N-ten ausführen).

@pragmaware IMO, eine Bibliothek sollte nicht

Wenn Sie japanischen Text lesen, lesen Sie den Artikel https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Nachdem ich diesen Kommentar geschrieben hatte, fand ich das Git-Repository für ptags (https://github.com/dalance/ptags). Die Seite ist auf Englisch geschrieben.)

Es meldet ein Tool namens ptags, das der Autor entwickelt hat. Das Tool ist in Rust geschrieben und verpackt Ctags.
Es führt Ctags parallel für die Menge der Eingaben aus.
Ich plündere nicht an seinem Inneren. Es führt jedoch offensichtlich mehrere Ctags-Prozesse aus.

Das Ergebnis kann sich sehen lassen. 5-mal schneller als einzelne Verarbeitung. Die Anzahl der CPUs wird nicht geschrieben. Die Speichergröße kann ausreichend sein (=128 GB). Der Autor führt 10 Mal ptags für denselben Eingabesatz aus, um den Seitencache heiß zu machen.

Obwohl diese Dinge in Wrappern wie Ptags erledigt werden sollten, ist es schwierig, dieses großartige Ergebnis zu ignorieren.
Ich habe schnell gehackt. https://github.com/masatake/ctags/tree/parallel
Die neu eingeführte Option --_parallel führt mehrere ctags-Prozesse in _parallel aus.

Die Anzahl der Worker-Prozesse, 8, ist fest codiert. Mein Note-PC hat 8 Kerne.
SPEICHER beträgt 32 GB. Die Zieleingabe ist der neueste Linux-Kernel-Quellbaum.
Meine .ctags sind genug behaart.

Das Ergebnis ist meist das gleiche: 2 ~ 3 mal schneller.

[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% 

(Ich habe beide Tags-Dateien verglichen. Es gibt keinen Unterschied.)

Alles andere als zufriedenstellend, aber es ist ein guter Anfang.

Ich frage mich, ob die Leistung der Arbeiter gesammelt werden muss oder nicht.

hi @masatake Ich versuche, alle meine offenen Tickets zu schließen, an denen ich nicht arbeiten möchte. Wenn Sie daran interessiert sind, an diesem Ticket zu arbeiten, könnten Sie den Text bitte in ein neues Ticket kopieren?

Ich werde in Zukunft an diesem Artikel arbeiten. Ich möchte diesen Punkt offen halten, weil die Aufzeichnung der Diskussion hier für mich wertvoll sein wird.

@masatake Sie können immer noch von einem neuen auf dieses Ticket verlinken und den vollständigen Verlauf beibehalten. Dies würde mir wirklich helfen, da ich versuche, meine Registerkarte "Probleme" für einen neuen Job aufzuräumen und ich nicht möchte, dass Unordnung wie dieses Ticket im Weg steht.

@fommil , ich sehe nicht, wie Sie @masatake , die treibende Kraft hinter Universal Ctags, mit 2.700 Commits gegenüber Ihrer Commit-Anzahl von Null überschreiben können. Sobald Sie einen Fehler öffnen (oder im Sprachgebrauch von GitHub "Problem"), wird dieser Fehler Eigentum des Projekts. Ich glaube, Sie können es deaktivieren und keine E-Mails darüber erhalten.

Wiedereröffnung.

@dtikhonov @masatake bitte dieses Ticket schließen. Es ist das einzige Ticket in meiner https://github.com/issues-Ansicht , das für meine Arbeit nicht relevant ist.

Es ist nicht möglich, ein Ticket aus dieser Ansicht zu entfernen, es sei denn, das Ticket ist geschlossen. Auch wenn ich mich abmelde.

Tatsächlich war mir nicht bewusst, dass Repo-Besitzer diese Kontrolle haben würden, als ich das Ticket erstellte, sonst hätte ich dies nicht getan.

Wenn Sie daran arbeiten möchten, erstellen Sie bitte ein neues Ticket und verweisen Sie auf dieses Ticket, alle Diskussionen bleiben erhalten. Oder kopieren Sie einfach den Inhalt von https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 in ein neues Ticket.

Ich denke, das ist nicht viel von mir zu verlangen.

Könnten Sie ein temporäres GitHub-Konto nur zum Kopieren und Einfügen erstellen?
Sie können also selbst kopieren und einfügen.
Anschließend können Sie das Konto entfernen.

klar, wenn das die einzige Möglichkeit ist, das zu beheben, kann ich das tun.

fertig! Danke, dass ich dieses Ticket schließen durfte. Es bereinigt meine TODO-Aufgabe erheblich.