Funktioniert Unix grep mit langen oder kurzen Suchbegriffen schneller?

Ist es schneller, nach langen oder kurzen Suchbegriffen zu suchen? Oder wirkt es sich überhaupt auf die Geschwindigkeit aus? Mit anderen Worten, sollten Sie die Suchbegriffe so genau wie möglich gestalten?

Es gibt mehr als 100 000 Dateien und jede Datei enthält zwischen 20 und mehr als 5000 Datenzeilen. Normalerweise wird der grep verwendet, um nur eine Instanz des Suchbegriffs zu finden.

Nehmen wir an, der Suchbegriff lautet SEARCHTERMund wird in einer Reihe wie dieser stehen:

NAD+DP+1234567890:92++UNIQUE+NAME+SEARCHTERM++12345+FI'

Ist es schneller, nach "SEARCH" oder "SEARCHTERM" zu suchen? Nehmen wir an, dass es uns in diesem Fall egal ist, ob wir Übereinstimmungen auch in anderen nicht verwandten Zeilen finden.

So mache ich es derzeit:

grep NAD+DP 123* | grep SEARCHTERM

Aber ich finde es immer noch ziemlich langsam. Normalerweise dauert es ungefähr 3-5 Minuten, um die Daten zu finden, selbst wenn ich den groben Dateinamen kenne, der den Bereich auf ungefähr 10 000 Dateien begrenzt.

Würde ein längerer oder kürzerer Suchbegriff helfen? Soweit ich weiß, sucht grep nach "Wortblöcken" einer bestimmten Länge?

Einige Referenzmaterialien:

GNU grep verwendet den bekannten Boyer-Moore-Algorithmus, der zuerst nach dem letzten Buchstaben der Zielzeichenfolge sucht und anhand einer Nachschlagetabelle angibt, wie weit die Eingabe übersprungen werden kann, wenn ein nicht übereinstimmendes Zeichen gefunden wird.

von Warum GNU grep ist schnell .

Der Algorithmus verarbeitet die gesuchte Zeichenfolge (das Muster) vor, nicht jedoch die gesuchte Zeichenfolge (den Text). [...] Im Allgemeinen läuft der Algorithmus mit zunehmender Musterlänge schneller.

vom Boyer-Moore-String-Suchalgorithmus .

Fazit: Verwenden Sie längere Saiten .

Nun ein bisschen Benchmark zum Spaß:

# Initialisation
cd $(mktemp -d) && dd if=/dev/urandom of=random bs=1M count=1000
# Version
grep --v` # grep (GNU grep) 2.9
# Benchmark
(for s in 'short' 'this is not so short and we could even consider this as pretty long'; do for t in {1..10}; do time grep "$s" random; done; done ) 2> result

Ergebnisse: 0,952 s ist der Durchschnitt für die kurze Saite, 0,244 s ist der Durchschnitt für die lange Saite.

NB : Die Länge ist nicht das einzige zu berücksichtigende Kriterium.

Sie können es mit SEARCH oder SEARCHTERM versuchen. Versuchen Sie auch, die Reihenfolge der beiden grep-Befehle zu ändern. Auf jeden Fall ist die einzig nützliche Option höchstwahrscheinlich die Verwendung mehrerer CPU-Kerne für eine Suche. Siehe den parallelBefehl.

Ich denke nicht, dass die Angabe eines spezifischeren Suchbegriffs es merklich schneller macht.

Bei so vielen zu durchsuchenden Dateien müssen Sie Ihre Daten irgendwie indizieren, um die Suche zu beschleunigen.

Ich kann einige Möglichkeiten vorschlagen:

• Erstellen Sie eine Datenbank (PostgreSQL oder MySQL), importieren Sie Ihre Daten in die Datenbank - eine Datei in einer Zeile, und fügen Sie den FTS-Index (Volltextsuche) hinzu. Erstellen Sie ein Dienstprogramm zum Abfragen der Datenbank.

• Importieren Sie Daten detaillierter in die Datenbank, wahrscheinlich eine Zeile in eine Zeile (oder möglicherweise mehr als eine Tabelle), und erstellen Sie Indizes, sodass Ihre Daten mithilfe von Indizes durchsucht werden können. Erstellen Sie ein Dienstprogramm zum Abfragen der Datenbank.

• Fügen Sie Ihre Dateien zum gitRepository hinzu, komprimieren Sie sie mit git gcund verwenden Sie sie git grepzum Suchen. Nach meiner Erfahrung git grepkann um den grepFaktor 10x-100x schneller als Standard sein .

Logischerweise erfordert eine kürzere Laufzeit weniger CPU-Zeit, wie dies grepder Fall sein wird

if (filechar[i] == pattern[i]) ...

weniger mal. In Wirklichkeit würde ich vermuten, dass a grepE / A-gebunden und nicht CPU-gebunden ist, also spielt es keine Rolle.