Speedtest File::Find

Wie ich hier ja schon berichtet habe, schien mit das Modul File::Find zu der Zeit etwas unflexibel. Grund dafür war die Tatsache, daß ich keine Dateiendungen übergeben konnte bzw. nicht festlegen konnte, wie viele Ebenen durchsucht werden sollen bzw. nur die aktuelle Ebene oder inklusive Unterebene.

Dies ist zwar natürlich Möglich, aber leider nur per Umweg.
Der Aufruf von File::Find erfolgt ja per

find(\&subrouine,$verzeichnis);

sub subroutine{
# Für eine Suche nach Dateiendung .htm
push @ergebnis,$File::Find::name if $File::Find::name=~ /\.htm$/i;
# Übrigens scheint $_ anstatt $File::Find::name auch zu funktionieren, ist aber nicht kommentiert, laß ich also besser weg...
}

Wie man sieht, ist die Suche nach verschiedenen Endungen dann etwas aufwändiger, da jede Endung per

if $File::Find::name=~ /\.ENDUNG$/i { }

oder ähnlich abgefragt werden muß.

Außerdem, wenn man die Suche auf nur die aktuelle Ebene beschränken will, muß man das wieder "per Hand" machen, also nicht per Parameter oder so... nene, mir kam das damals schon seltsam vor...

Und gerade eben hatte ich mal ein paar Minuten Zeit und dachte mir, ich messe mal die Performance von File::Find gegenüber meiner Routine get_all_files.
Und siehe da: Nicht nur, daß ich, zumindest für mich, leichter zu einem vernünftigen Ergebnis komme, nee, File::Find ist auch noch langsamer! Meine Routine ist ca. 10 Prozent schneller bei einer Suche in einem Ordner inklusive Unterordner nach 3 Endungen.

Die Versuchscodes waren folgende

@dateien=get_all_files('c:/htdocs/',1,'.shtml.htm.txt');

UND
use File::Find;
find (\&wanted,"c:/htdocs");

sub wanted{

push @erg,$File::Find::name if ($File::Find::name=~ /\.shtml$/i || $File::Find::name=~ /\.htm$/i || $File::Find::name=~ /\.txt$/i);

}

Nun, gefunden wurden im Test je ca. 114000 Dateien, Variante 1 brauchte ca. 16 Sekunden, Variante 2 ca. 18 Sekunden.
get_all_files ist also (zumindest für diesen Fall) schneller! Und das, obwohl ich damals bei der Erstellung noch nicht mal großartig auf eine Optimierung geachtet habe.

Woran liegts?
Nun, ich werde mir jetzt nicht die Arbeit machen und File::File zu zerlegen um zu sehen, was wo langsamer ist.
Ich könnte mir aber denken, daß es vor allem daran liegt, daß File::Find wesentlich mehr kann als meine kleine Unterfunktion. Und da liegt wahrscheinlich auch das Problem: Solche großen universellen Module sind oft aufgrund der vielen Funktionen eben manchmal auch langsamer.

Ich werde zuindest für solche Anwendungen in Zukunft lieber nicht File::Find verwenden, sondern bei meinem Script bleiben.

Das Script gibts übrigens hier zum Angucken und auch Verwenden. Ich habe es der Einfachheit halber in eine eigene Library namens lib.pl geschrieben und kann hier gedownloadet werden.
Der erste, ursprüngliche Artikel, in dem die Routine entstanden ist und erklärt wird, ist hier zu finden.

Kommentare zum Beitrag "Speedtest File::Find"

Kommentar von Admin

Übrigens nochmal bezüglich File::Find und $_:
Ich hab da nochmal tiefer nachgegraben (eine Ausgabe der Werte hätte es aber auch getan...) und "herausgefunden", daß in $_ der Dateiname OHNE Verzeichnisname steht. In $File::Find::name steht der volle Dateiname, und in $File::Find::dir steht das Verzeichnis ohne Dateiname.

Kommentar von Guido Beckmann

Der Inhalt von $_ ist Dokumentiert. Er hängt von der Option 'no_chdir' ab.
Hier wäre der Inhalt von $_ ein anderer:

find({no_chdir => 1 ,wanted => \&wanted }, $dir)

Thema: Perl Leistungsoptimiert Dateien Script

Der Beitrag "Speedtest File::Find" wurde 11196 mal gelesen.

Es wurde 4 x über diesen Beitrag abgestimmt.
Die durchschnittliche Beurteilung liegt bei
2.5 (1 = sehr gut - 6 = grottenschlecht).