2010-01-04T12:12:14 bianca

Ich habe ohnehin das Gefühl, dass man bei den heutigen schnellen CPU's die echten Bremsen nicht im kleinsten Minidetail findet sondern an Ein- oder Ausgabeschnittstellen, die man oft bestimmt mit einem einfachen time() messen kann :)

das ist nicht ganz richtig. echte bremsen sind die teile im code, die oft aufgerufen werden. und die lohnt es sich zu optimieren. je wesentlicher ein code-stück für die gesamtzeit, desto eher kann man es auch verantworten, es etwas unleserlicher zu machen.
ich treffe in verschiedenen foren und arbeitsplätzen oft zum einen auf die gruppe, die sagt "ach, optimieren ist an sich zeitverschwendung - es hängt meist eh an der langsamen datenbank" - da sage ich, falsch, wenn die datenbank die bremse ist, kannst du beispielsweise eine suchmaschine statt einer datenbank einsetzen, das hilft oft. kein grund, den perlcode nicht zu optimieren.
die anderen sind dann selbsternannte experten, die glauben, optimieren ist cool und schreiben unleserliche codestücke, bei denen sich im schlimmsten fall rausstellt, dass sie sogar langsamer sind als schöne, perlige lösungen mit map und dergleichen. und die eventuell auch kaum ausschlaggebend sind.

man muss die goldene mitte finden. wer optimierung komplett unnötig findet, der beachtet nicht, dass er z.b. von den vielen teilen in modulen profitiert, die in C geschrieben sind. würde jemand komplett darauf verzichten wollen? ich glaube, das würde unsere anwendungen teilweise wahnsinnig langsam machen.
wer blind drauflosoptimiert, weil er denkt, was cool und kurz aussieht, muss ja langsam sein, und stattdessen unleserlichen code in java- oder C-style hinschreibt, ohne es zu testen, liegt auch falsch.

ich habe mal perlgolf gespielt und dabei naturgemäss eine möglichst kurze lösung gesucht. perlgolf ist nicht unbedingt ein gutes training für optimierung. interessanterweise war es aber in einem fall tatsächlich so, dass ich mit der kürzeren lösung auch einen viel schnelleren algorithmus gefunden hatte. überraschungen gibt es immer wieder.