Quote

HTC z.b. wäre nicht so schnell, wenn ich nicht mit Benchmarks die Stellen herausgefunden hätte, die Zeit kosten. Man sucht sich ggfs. mit einem Profiler die Schwachstellen

Das letztere ist es! Man sucht mit einem "Profiler" in einer "Applikation" nach Engstellen. Nicht aber im vorhinein sinnlos Benchmarken.

Quote

Indem man hier z.B. fetchrow_hashref durch fetchrow_arrayref ersetzt, sieht man dann ggfs., dass das schneller ist. Dann muss man sich die Frage stellen, ist das sinnvoll,

Die Frage muss man sich nicht stellen da sie sinnlos ist.

fetchrow_arrayref sollte schneller sein, die erkentniss darüber ist aber total irrelevant. Wenn man eine Applikation hat und z.B. 20 Einträge anzeigt wird es kaum eine Rolle spielen ob die Datenbank aktion nun 3 oder 4 Millisekunden braucht wenn ich das eine oder das andere nutze. Vorallem dann nicht wenn anderer code 100ms irgendwo verbrät und 99% der laufzeit ausmachen. Soetwas ist dann typisches Premature Optimization

Bei der Entwicklung wird aber ein Hashzugriff angenehmer sein, und man sollte so Entwickeln wie es am einfachsten und lesbarsten ist.

Wenn Performance Probleme auftreten Profilet man seine Applikation und verbessert nur die akuten stellen. Und nach jeder änderung Pofilet man erneuert seine Applikation um zu schauen ob es änderungen gebracht hat. Man geht nicht hin und versucht einzelne Stückchen Code zu extrahieren und diese zu Benchmarken.

Wenn eine Subroutine sehr langsam ist kann man zum Beispiel die Subroutine optimieren oder aber vielleicht findet sich ja ein Algorithmus oder eine Optimierung an einer ganz anderen Stelle die den aufruf der Sub um ein vielfaches reduziert und so sehr viel mehr Performance gewinnt.

Der Schlüssel ist Profilen nicht Benchmarken. Profilen geht aber nur vernünftig in einer Applikation mit Live Daten, da wo es wichtig ist.

Quote

In HTC gibt es z.B. jede Menge stellen, in denen ich zugunsten der Schnelligkeit auf die Lesbarkeit verzichtet habe, aber das ist ok, weil es interner Code ist, der so oft ausgeführt wird und im Vergleich dazu selten angefasst werden muss. Das muss man immer abwägen, und ein isolierter Benchmark gibt einem eine Idee davon, ob es überhaupt lohnt.

Ein Benchmark gibt dir gar keine Idee davon ob es was gebracht hat oder nicht. Wenn deine Optimierte stelle jetzt zwar 50% schneller ist von 5ms auf 2.5ms aber die Stelle nur alle jubell jahre einmal aufgerufen wurde und 0.0000001% der gesammten Laufzeit ausgemacht hat dann hat deine Optimierung absolut nix gebracht. Ausser Zeitverschwendung.

Quote

Benchmarks generell als sinnlos abzutun, halte ich für falsch. Man muss nur wissen, wie man sie benutzt.

Da mag ich dir nur minimal zustimmen.

Wenn man Profilet sind Benchmark nahezu sinnlos. Benchmarks haben das Problem das sie keine Reale umgebung darstellen, damit man etwas benchmarken kann muss man den Context so klein wie Möglich halten. Da läuft man aber in gefahr sachen zu Benchmarken und stellen zu Optimieren die volkommen irrelevant sind.

Erhöht man den Context zu einer Realen Applikation ist es nahezu unmöglich durch einen Benchmark die stelle zu finden die relevant sind, hier geht man dann wieder in Richtung Profilen.

Ansonsten möchte ich ja nicht anzweifeln das du durch Benchmarken die Performance verbessert hast. Die Frage ist nur wenn du Profilst ob es nicht ansatzpunkte gibt die man hätte besser Optimieren können die mehr gebracht hätten. Oder ob alles überhaupt nötig war, sprich du dir nicht einiges an aufwand gespart hättest.

Von daher sehe ich Benchmarks schon als Sinnlos an. Lieber profilen. Vorallem gewöhnt man sich durch Benchmarks irgendwelche "Optimierungen" an, die am ende eigentlich nichts bringen auser Code undurchsichtig oder nicht mehr wartbar etc. zu machen.