Am Die, 2003-06-24 um 00.50 schrieb David Haller:
Hello,
On Mon, 23 Jun 2003, Ralf Corsepius wrote:
Am Mon, 2003-06-23 um 03.00 schrieb David Haller: [..]
Das ist der gleiche Fehler wie von grepmail. Versuch das mal mit ner Datei von ein paar 100 MB!!! 100MB Dateien sind ein extremer Sonderfall.
Nicht bei grepmail... Das Teil frisst (oder frass zumindest) Speicher wie bekloppt. Je nach Hauptspeicher geht's halt ab einer gewissen Dateigroesse nicht mehr...
.. eben, 100MB im Speicher sind heutzutage (auf Home-Desktops noch) nicht normal.
Ja, bei derartigen Extremfällen scheitert Einlesen in eine einzelne Liste, aber ... [..]
foreach (@zeilen) { # Zeilen abklappern, Zeile wird in $_ abgelegt
*ARGH* Hier wird's dann wirklich doof, wenn man sowieso zeilenweise liest, kann man gleich die Datei hernehmen.
... Jan's Lösung ist schon bei Dateien mit wenigen 100 Zeilen um mehrere 10-Potenzen schneller.
*huch* ;) Aehm, nunja, siehe unten.
In einer vergleichbaren Anwendung habe ich schon Faktor ca. 20-50 beobachtet (mit perl < 0.5.6)
D.h. je nach Anwendungsgebiet ist mal die eine oder die andere Lösung sinnvoller, schneller oder "besser".
Ack. Es wurde halt nix zur Dateigroesse gesagt, und bevor z.B. ein script wg. Speichermangel gar nicht laeuft, soll's ruhig etwas laenger laufen... Im einem Fall war es ein Code-Generator, der ca. 100 Mal pro "make" Lauf aufgerufen wird. < 0.5 sec statt > 10 sec wirken sich dabei deutlich aus.
So, nun interessiert mich das jetzt aber mal... ;)
Die Rechnung ist im Prinzip einfach: 1 x File-I/O + n x Mem-Zugriff gegen n x ( File-I/O + Mem-Zugriff ) [Leg die Dateien auf ein nfs-gemountetes File-System und/oder ein mit I/O belastes System.] Mag sein, dass neuere Perl/glibc/Linux-Implementierungen ein günstigers Caching verwenden als ältere Versionen oder sich neuere HW derart auswirkt, dass die Performanceunterschiede nicht mehr so gravierend auswirken. Ralf