Thread pm-Modul: DATA-Teil und 1; inkompatibel?
(15 answers)
Opened by RalphFFM at 2008-01-09 11:08 RalphFFM+2008-01-11 09:27:27-- Kann deinen Satz nicht so ganz folgen. Ob du nun Code: (dl
)
while (<DATA>) oder Code: (dl
)
while (my $line = <DATA>) 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... Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
|