[linux-l] Ruby: sehr cool, aber auch sehr laaaahm... wie geht's schneller?!

[Steffen Dettmer]

* Oliver Bandel wrote on Tue, Aug 22, 2006 at 19:50 +0200:
> > > ========================================
> > >   foreach (@ARGV)
> > >   {
> > >     open FILE, "$_"  or next;
> > >     while(<FILE>)
> > >     {
> > >       if( /^begin/ )
> > >       {
> > >         print;
> > >         #close FILE;
> > >         #next;
> > >       }
> > >     }
> > >     close FILE;
> > >   }
> > > ========================================
> 
> Aber wenn Du das Script da oben nimmst und die Kommentarzeichen entfernst,
> sollte es erheblich schneller werden, falls das Pattern kurz hinter dem
> Header der Mail/des Postings zu finden ist.

Jaja, schon klar, solange es ein begin gibt und dieses früh steht (wovon
man dann ausgehen kann).

> > Das oben funktioniert, weil "while(<FILE>)" mit Fehler zurückkommt, wenn
> > das "#next" auf der geschlossenen Datei liest und "fertig" ist?
> 
> Die Sache mit dem "next" (das next hinter dem "open") dient dazu, bei
> unsinnigem Filenamen nicht in Probleme zu rasseln; üblich ist es ja,
> mit "die" eine Fehlermeldung auszugeben und das Programm abzubrechen;

Üblich? :) Kommt auf's Programm an, denke ich.

> aber hier fand ich es sinnvoller, stattdessen Filenamen, die unsinng
> sind, oder die zu Files gehören, die man nicht lesen kann, einfach zu
> ignorieren und dann mit dem nächsten Filenamen weiter zu machen.

sorry, ich meinte das 2. next.

> "#next" ist ein auskommentiertes "next".
> Es funktioniert also garnicht.
> Ebenso ist es mit "#close FILE".

sorry, ich war wohl immer noch nicht 100% präzise, ich meinte natürlich
die Funktion des next's, was im Beispiel auskommentiert ist, wenn es
nicht mehr auskommentiert wäre. Das ein auskommentiertes next nichts tut
war mit bereits bekannt :-)

> > Der RegEx kann optimieren, wenn's halt nicht am Anfang war und muss
> > nicht weitersuchen, strstr weiss das aber ja nicht. Dann lieber
> > substr auf strlen des "begin" und "eq" oder strcmp Vergleiche mit
> > dem Ergebnis, strncmp sollte hier noch schneller sein, wenn man es
> > hat. Sowas ist dann eigentlich immer sehr schnell, es "fasst keine
> > nicht benötigen Bytes an", bei langen Zeilen hier natürlich sehr
> > wichtig. Ich glaub, schneller kriegt man das dann nicht.
> 
> *Äääähem*, *Räääuüüüspeer*, ... ich wollte nicht am Perl optimieren,
> sondern am Ruby....

Naja, die Problematik an sich sollte da die gleiche sein - am Ende kommt
ja in beiden Fällen Maschinencode raus :)

> > Das langsame kommt dann wieder vom "gets" oder was man da nimmt, das
> > muss mindestens newlines suchen.
> 
> In der C-Variante hatte ich fgets() genommen; aber mit max. 10000
> Zeichen Buffersize. OK, hätte ich auch kürzer machen können (so lang
> wie der Keyword-String), aber dann hätte man ja evtl. etliche Aufrufe,
> wenn das nächste "\n" noch lange auf sich warten lässt....
> 
> .... Ich könnte auch sagen: Nach Ende des Headers suche maximal
> 50 Zeilen und wenn das Keyword nicht gefunden wurde, gib auf,
> es wird nicht ein solches File sein.
> 
> Naja, dieses ganze Optimierungszeugs wollte ich aber erst mal
> nicht machen.

Die sind ja auch nicht ganz fair, weil sich das Verhalten ändert ;)

> Ich hatte so ein Tool schon mal angefangen, aber das dann nicht weiter
> verfolgt. (Naja, wenn jemand das finanziert hätte, wäre es wohl schon
> fertig ;-))

Na gut, dass Tool gibt's doch und heisst grep, oder?

> Da ich gerade wieder in einem Umzug stecke und die letzten Wochen
> Dielen geschliffen habe, sitz ich Abends eh mit Staub auf den Pupillen
> am Rechner ;-) Und wenn man den dann Abends (wie es sich für einen
> ordentlichen Dielenschleifer so gehört;-)) den Staub mit nem Bier
> runter spült, ist's einem egal, ob man bei einer Sprache, die man
> garnicht einsetzen will noch optimieren kann.

:-)

> Ich wollte doch bloß etwas Ruby machen.... aber das sollte sich doch
> bitteschön wenigstens auch ein *bischen* optimieren lassen....

Naja, oder Du trinkst noch ein paar Bier mehr und dann ist auch das
egal? :)

> ...ausser, Ruby braucht auch bei 10 und auch bei 100 mal so vielen/großen
> Files immernoch 3,6 Sekunden.... vielleicht geht das dann ja auch bei
> 10 GB und 120 TB?!
> "Hurraa, hurraa, egal was immer ich auch berechne, ich schaffe es in
> 3,6 Sekunden!" :)

Ja, das wäre ein prima Grund, ruby zu nehmen. Auch für das Berechnen
komplexer Sachen und so. Vielleicht ist das eine Ruby Eigenschaft. Ein
Programm dauert immer 3,6 Sekunden. lol das wäre cool

> > Ja, komisch...
> > 
> Ha, ha, ha, :( wenn Du nochmal "komisch" sagst, fange ich noch an zu
> lachen... ;-(

:-) 

Komisch.

:-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.