ich halte mich meist an die regeln:
x) optimiere nicht
x) wenn du umbedingt optimieren musst, tu es spaeter...

RalphFFM+2008-01-11 09:27:27--

Ich weiß aber auch, daß voreilige Performanceoptimierung m.W. i.A. ein Fehler ist
solange man die Perl-Compilierungs-Interna nicht so gut wie seine Hosentasche
kennt. (-> Frage: Seht ihr das eigentlich genauso?)

ich optimiere wahnsinnig gern, aber da ich gerne mal benchmarke und das schon
bei vielen sachen ziemlich gut im gefühl habe, was schnell sein könnte, finde ich das ok.
wenn man sich nicht sicher ist, sollte man benchmarken.
ich habe schon erlebt, dass mir leute erzählen, sie haben den code etwas komplizierter
geschrieben, weil das halt schneller sei, und wenn ich es gebenchmarkt habe, kam sogar
das gegenteil raus.
man sollte aber auch bedenken, dass sich in perl die dinge von version zu version und
plattform anders verhalten können, von daher sollte man das wie gesagt schon etwas
im gefühl haben.
nicht zu früh optimieren hat schon seinen grund, aber wenn ich ein programm plane,
dann berücksichtige ich doch schon implizit performance, indem ich mir überlege,
wo ich wie daten speichere etc.

RalphFFM+2008-01-11 09:27:27--

@sid burn: Ja. Nur mit der Variablenlösung müßten wieder alle Daten im
Arbeitsspeicher vorgehalten werden was ich eigentlich vermeiden wollte.

Kann deinen Satz nicht so ganz folgen.

Ob du nun

oder


schreibst macht für den Arbeitsspeicher nicht viel unterschied. Es wird jeweils immer eine Zeile in eine variable Kopiert. Ohne Angabe ist es halt die Default variable "$_" und mit ist es "$line".

Man sollte nur deswegen eine Variable angeben weil beim oberen Beispiel $_ vorher nicht lokalisiert wird. Du könntest zwar explizit "local $_ = <DATA>" schreiben aber die direkte Verwendung einer Variable hat noch den Vorteil das es die Lesbarkeit deines Codes erhöht.

-------------------------------------

Optimieren während des Schreibens tut ich gar nicht, weil ich es für unaussagekräftig halte. ich achte primär nur darauf das der Code lesbar und verständlich ist, und oder Modular, erweiterbar etc. ist.

Zum anderen kann man es nicht immer vernünftig Benchmarken. Gutes Beispiel ist z.B. in Class::Accessor zu finden. Dort wird auch gebenchmarkt wie schnell diese Methoden zu normal generierten Methoden sind. Mag zwar sein das normale Methodenaufrufe in der Regel schneller sind. Selbst wenn du jetzt sagst ein normaler Subroutinen aufruf wäre 5 mal schneller. Dann kannst du nicht sagen das jede Subroutine 5 mal schneller/langsamer wird.

Den in den Subroutinen machst du ja auch was. Datenbank abfragen, Dateien abrufen etc. Und die Zeit des Methodenaufrufs macht vielleicht nur 0.0001% der Zeit aus. Von daher effektiv gesehen ist es theoretisch gesehen 5 mal schneller im direkten vergleich. In einer normalen Applikation aber total irrelevant. Auuser du rufst die Methode jetzt zufällig mehrere billionen mal hintereinander auf. ;) Aber dann sollte es auch egal sein ob deine Code dann 5 jahre oder 5 Jahre + 1 Tag benötigt.

Kurz gesagt: Von vorneherein Optimieren würde ich nie tun. Und wie bereits gesagt wurde. Nicht einfach wahllos optimieren. Sondern mit einem Profiler engpässe finden.

Zum anderen wie pq bereits sagte kannst du in der regel mehr Gewinn machen wenn du vorher vernünftig plannst. Also eine Datenbank z.B. vernünftig aufgebaut ist. Wenn du Berechnungen in einer Routine machst diese vorrechnen lassen oder auslagern. Anstatt if/elsif/elsif/else abfragen hash strukturen nehmen. Wenn das ergebnis einer Soubroutine bei gleichen input immer gleich ist vielleicht den Rückgabewert Cachen (z.B. mit den Memoize Modulen). Oder generell Caching. Es gibt mehr Sachen wo du durch Planung Performance gewinnst. An der Sprache selber würde ich keine Ausdrücke Optimieren auser du hast vorher mit einem Profiling festgestellt es ist die Zeile die dein Programm so langsam macht.

Der Verlust an lesbarkeit (und letztendlich wartbarkeit) rechtfertig es nicht in vorneherein zu optimieren. Aber auch im nachhinein nicht. Man muss sich halt klar werden das alles eben etwas Zeit beansprucht. Und da muss man halt auch abwegen ob die Performance Gewinn eine erhöhte komplexität für eine Optimierung lohnt.

Immerhin kostet diese auch Zeit. Beim Optimieren und beim späteren lesen, wenn du Wartungsarbeiten machst. Die erhöhte komplexität kann auch zu problemen (Fehler) führen, wenn du etwas falsch verstanden hast. Prozessoren und Speichern hingegen kannst du einfach nachkaufen und den Rechner/Server aufrüsten...

@sid burn: Ich habe mich glaube ich unglücklich ausgedrückt. Bei den im Arbeitsspeicher
vorgehaltenen Daten wollte ich mich nicht auf das "while ..." beziehen, sondern auf:
"Ansonsten wenn du Statische Daten hast würde ich diese direkt in einer variable Packen
und diese dann am anfang des Modules initialisieren. Anstatt womöglich jedesmal die Daten
Zeile für Zeile durchzugehen und die Daten wahrscheinlich noch aufzusplitten etc."

Daher vermute ich sind wir völlig einer Meinung. Andernfalls kann es sein, daß ich Dich
vielleicht noch nicht vollständig verstanden habe mit dem wie Du das meinst.
Programmieren hat finde ich nicht nur alleine mit Fleiß zu tun, sondern auch enorm mit
Kreativität. Und nicht selten gibt es Alternativen, an die ich nicht gerade gedacht habe. :-]
Über Ideen bin ich immer sehr dankbar.

Insbesondere bei Modulen sollte man darauf achten, das Dateihandle DATA nach Gebrauch zu schließen. Sonst kommt es vor, dass die Modul-Datei für die gesamte Laufzeit des Programmes geöffnet bleibt.

Naja, und dass man vor while(<DATA>) (ebenfalls insbesondere in Modulen) nicht vergessen sollte, local($_); zu schreiben, wollte ich auch noch erwähnen :)

RalphFFM+2008-01-11 18:32:54--

@sid burn: Ich habe mich glaube ich unglücklich ausgedrückt. Bei den im Arbeitsspeicher
vorgehaltenen Daten wollte ich mich nicht auf das "while ..." beziehen, sondern auf:
"Ansonsten wenn du Statische Daten hast würde ich diese direkt in einer variable Packen
und diese dann am anfang des Modules initialisieren. Anstatt womöglich jedesmal die Daten
Zeile für Zeile durchzugehen und die Daten wahrscheinlich noch aufzusplitten etc."

Daher vermute ich sind wir völlig einer Meinung. Andernfalls kann es sein, daß ich Dich
vielleicht noch nicht vollständig verstanden habe mit dem wie Du das meinst.
Programmieren hat finde ich nicht nur alleine mit Fleiß zu tun, sondern auch enorm mit
Kreativität. Und nicht selten gibt es Alternativen, an die ich nicht gerade gedacht habe. :-]
Über Ideen bin ich immer sehr dankbar.

Oh stimmt,
dass hatte ich ja auch noch geschrieben. ^^

Aber ne, ich meinte es schon so wie ich es geschrieben habe. Wenn du in deinem Programmcode ständig <DATA> immer wieder von neuen durchgehst, und die Daten auch noch aufbereiten musst "mit split trennen etc." dann würde ich mir eine Routine schreiben die das ganze einmal macht und dir eine Datenstruktur zurück gibt. Und diese Datenstruktur dann mehrmals verwenden.

Ein Schlüssel für Performance heißt auch: "Lasse alles immer nur einmal berechnen". ;)

Wenn es natürlich Gigabyte an Daten sind ist das ganze natürlich nicht mehr so Optimal. Aber Gigybyte an Daten hängt man ja üblicherweise nicht an <DATA> an.