Viele RegExp Checks auf viele Dateien (Allgemeines zu Perl)

Tr0Nix

2007-12-21 10:51

User since
2006-11-21
44 Artikel
BenutzerIn
[default_avatar]

Hallo zusammen

Ich mache mich in wenigen Wochen an meine Diplomarbeit. Dabei geht es grob gesagt um viele Regular Expressions, welche auf viele Dateien angewendet werden.

Das Script, welches dies aktuell löst, ermittelt mit File::Find die Dateien und führt auf jede gefundene Datei eine Callback Funktion aus.

Die Callback Funktion wiederrum öffnet die übergebene Datei und liest diese Zeilenweise ein, wobei jede Zeile durch etwa 20+ Regular Expressions geschickt wird um gewisse Prüfungen vorzunehmen.

Im Verlaufe meiner Diplomarbeit möchte ich nun das Script von Scratch auf neu programmieren und die Regular Expressions überarbeiten. Da Performance ein ausschlagsgebender Punkt ist, wollte ich euch Fragen, ob ihr mir Tipps oder Anlaufsstellen geben könnt, die mich bei der Arbeit unterstützen. Auf Weihnachten gibts auf alle Fälle das O'Reilly Regular Expressions schlag-mich-tot-Kompendium :).

Umfang:
Die Files sind in erster Linie Sourcecode. Sprich in den allermeisten Fällen < 1MB, dafür sehr viele Dateien.

Fragen die beispielsweise bei mir aufgetaucht sind:
- Macht es Sinn, die Datei zuerst komplett ins Memory einzulesen statt Zeilenweise mittels $zeile = <FD>?
- Die aktuellen Regular Expressions nutzen alle markierte Subexpressions (also die runden Klammern () um anschliessend mit $1, $2... zuzugreifen) auch wenn diese Informationen teilweise nicht genutzt werden. Kann das die Performance beeinträchtigen?
- Sind Regular Expressions CPU-lastig? Das Script läuft zeitweise auf einem Multi-CPU Sun Server -> Multithreading

Bin gespannt auf eure Meinungen/Ideen,

liebe Grüsse
tr0nix

renee

2007-12-21 10:58

User since
2003-08-04
14371 Artikel
ModeratorIn

Tr0Nix+2007-12-21 09:51:41--
Hallo zusammen

[...]

Umfang:
Die Files sind in erster Linie Sourcecode. Sprich in den allermeisten Fällen < 1MB, dafür sehr viele Dateien.

Fragen die beispielsweise bei mir aufgetaucht sind:
- Macht es Sinn, die Datei zuerst komplett ins Memory einzulesen statt Zeilenweise mittels $zeile = <FD>?

Kann man so allgemein nicht sagen. Wenn es Bedingungen gibt, die ein "Abbruch" der Analyse bedingen, ist es eher kontraproduktiv. Wenn Du aber Reguläre Ausdrücke hast, die im Prinzip über viele Zeilen (der einzulesendende) gehen, kann es sinnvoll sein.

Quote
- Die aktuellen Regular Expressions nutzen alle markierte Subexpressions (also die runden Klammern () um anschliessend mit $1, $2... zuzugreifen) auch wenn diese Informationen teilweise nicht genutzt werden. Kann das die Performance beeinträchtigen?
- Sind Regular Expressions CPU-lastig? Das Script läuft zeitweise auf einem Multi-CPU Sun Server -> Multithreading

Das "Compilieren" der RegEx ist schon relativ aufwändig. Deshalb wäre es eventuell geschickt, vorkompilierte RegEx zu verwenden.

Ganz interessant wäre zu wissen, was das eigentliche Ziel ist. Was analysierst Du denn mit den Regulären Ausdrücken? Ist es Perl-Code?

Auf jeden Fall lässt sich nichts eindeutig beantworten, ohne Code und Ziel zu kennen.

Über was geht denn die Diplomarbeit?

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

MisterL

2007-12-21 10:59

User since
2006-07-05
334 Artikel
BenutzerIn
[default_avatar]

Also die Thematik würde mich auch mal interessieren ;-)
Aber ich sehe gerade, dass das Foo Magazin (http://www.foo-magazin.de/#d14) etwas dazu enthält. Ob der Einblick 6 Euro wert ist, kann der Herausgeber wohl besser sagen wie unsereins....

“Perl is the only language that looks the same before and after RSA encryption.”

renee

2007-12-21 11:03

User since
2003-08-04
14371 Artikel
ModeratorIn

Der Artikel dazu gibt es als Leseprobe, wenn es nur um den RegEx-Artikel geht, sind die 6,00 EUR also nicht nötig (auch wenn ich jetzt nicht gerade unternehmerisch handele ;-) ).

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

Tr0Nix

2007-12-21 11:10

User since
2006-11-21
44 Artikel
BenutzerIn
[default_avatar]

renee+2007-12-21 09:58:59--
Kann man so allgemein nicht sagen. Wenn es Bedingungen gibt, die ein "Abbruch" der Analyse bedingen, ist es eher kontraproduktiv. Wenn Du aber Reguläre Ausdrücke hast, die im Prinzip über viele Zeilen (der einzulesendende) gehen, kann es sinnvoll sein.

Das ist ein guter Input! Aktuell geht jede Zeile komplett durch alle Checks durch und es könnte auch mehrere Checks triggern (wieso erläutere ich bei deiner nächsten Frage).

Quote
Das "Compilieren" der RegEx ist schon relativ aufwändig. Deshalb wäre es eventuell geschickt, vorkompilierte RegEx zu verwenden.

Ganz interessant wäre zu wissen, was das eigentliche Ziel ist. Was analysierst Du denn mit den Regulären Ausdrücken? Ist es Perl-Code?

Aktuell gibt es 2 Versionen des Parsers, eine für Java und eine für PL1. Im Prinzip sind beide Scripts jedoch 90% gleich und unterscheiden sich nur in ein paar syntaxabhängigen Regular Expressions - deshalb möchte ich das so überarbeiten, dass man ein Hauptprogramm hat, welches die Checks abhängig der Sprache hinzulinkt (falls in Zukunft noch andere Sprachen kommen würden).

Quote
Über was geht denn die Diplomarbeit?

Um das Erkennen von möglicherweise ungewünschten Informationen in Sourcecodes. Beispielsweise in Kommentaren oder Ausdrücken, die auf schlechten bzw. hartkodierten Programmierstil hinweisen (if $kunde == "foo@bar.com"...). Hier können natürlich auch mehrere Checks "aufleuchten" - wegen einer E-Mail und wegen eines Vergleichs mit einer Konstante.

// Edit:
Hab gerade gebrowsed nach vorkompilierten Regular Expressions - das ist wirklich ein guter Tipp! Aktuell sind die das nämlich nicht!

renee

2007-12-21 11:22

User since
2003-08-04
14371 Artikel
ModeratorIn

Tr0Nix+2007-12-21 10:10:58--
Quote
Über was geht denn die Diplomarbeit?

Um das Erkennen von möglicherweise ungewünschten Informationen in Sourcecodes. Beispielsweise in Kommentaren oder Ausdrücken, die auf schlechten bzw. hartkodierten Programmierstil hinweisen (if $kunde == "foo@bar.com"...). Hier können natürlich auch mehrere Checks "aufleuchten" - wegen einer E-Mail und wegen eines Vergleichs mit einer Konstante.

Sehr interessant. Ist die Arbeit dann öffentlich zugänglich?

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

Tr0Nix

2007-12-21 11:27

User since
2006-11-21
44 Artikel
BenutzerIn
[default_avatar]

Müsste ich abklären da ich es für meinen Arbeitgeber schreibe. Es geht dabei "weniger" um den Programmierstil zu prüfen (wobei solche Informationen im Code eigentlich ja auch schlechter Stil ist), als darum, mögliche kritische Daten aus dem Code zu entfernen. Ich werde aber sicherlich für die Diplomfeier (wenn ich es schaffe :p) etwas vorbereiten, was öffentlich präsentiert werden kann - das kann ich dann gerne hier publizieren!

nepos

2007-12-21 12:26

User since
2005-08-17
1420 Artikel
BenutzerIn

Wenn du mit () geklammerte Daten eigentlich nicht weiter brauchst, kannst du stattdessen (?:...) schreiben. Das sollte dann auch ein wenig fixer sein.

renee

2007-12-21 13:15

User since
2003-08-04
14371 Artikel
ModeratorIn

Jepp, ist schneller:

Code (perl): (dl )

#!/usr/bin/perl

use strict;
use warnings;
use Benchmark qw(:all);

my $string = "Dies ist ein Test mit einer längeren Zeile";

timethese(
  5000000,
  {
     capture    => sub { $string =~ /(es).*?T(es).*(ei)/},
     noncapture => sub { $string =~ /(?:es).*?T(?:es).*(?:ei)/ },
  }
);

Code: (dl )

C:\>benchmark.pl
Benchmark: timing 5000000 iterations of capture, noncapture...
   capture:  8 wallclock secs ( 8.53 usr +  0.00 sys =  8.53 CPU) @ 586097.76/s (n=5000000)
noncapture:  5 wallclock secs ( 4.91 usr +  0.00 sys =  4.91 CPU) @ 1019160.21/s (n=5000000)

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

Tr0Nix

2007-12-21 13:33

User since
2006-11-21
44 Artikel
BenutzerIn
[default_avatar]

Interessant interessant, was man nicht alles lernt! Genau solche Optimierungen suche ich!