P
volkard schrieb:
aber du kannst dir schon vorstellen, daß man software so baut, daß man von anfang an überhaupt keinen wert auf performance legt und man am ende sehr unzufrieden ist und daß man dann doch optimiert und beim optimieren das tolle design total zerstört und das gibt dann häßliche unwartbare frickelsoftware.
Es gibt etliche Punkte, an denen man sich von vorneherein bessere oder schlechtere Karten verschafft und die zu selten ins Bewußtsein der Programmierer gerückt zu sein scheinen, weil die normalerweise an einem schnellen PC sitzen, da fällt's lange nicht auf, wenn Rechenzeit sinnlos verbrunzt wird. Natürlich gibt es weitere Aspekte, aber ich möchte das nur exemplarisch anreißen.
1. Systemdesign nach Umgebung
In Anbetracht der Targetplattform(en) muß eine grundlegende Strategie unter Berücksichtigung auch der Performance gefunden werden. Also, wenn ich eine API bedienen muß, die Hyperthreading anbietet, suche ich nach parallelisierbaren oder gänzlich unabhängigen Jobs, was sich als Ansatz eher verbietet, wenn einem ein nackter 8-Bit µC als Target ohne OS und Framework unterkommt. Wahrscheinlich werde ich auf dem PC nicht die optimale Strategie für den Ansatz finden, da ich eher auf den kleinen Kisten unterwegs bin; umgedreht bekomme ich immer wieder "gestückeltes" Polling zu sehen, das nur dann funktioniert, wenn die Plattform schnell im Vergleich zur Aufgabe ist. Haarsträubendes Zeug, das auch nur jemand einfallen kann, der glaubt, daß unter 16 Bit getrommelt werden muß.
2. Summe der kleinen Sünden
Immer wieder nervend sind die Sachen, bei denen Mehrfachberechnungen immer des Gleichen angestoßen werden, weil Leute statt Zwischenergebnisse zu verwenden zweimal das Gleiche hinpinseln, frei nach dem Motto "soll sich der Compiler doch drum kümmern". Also z.B. e1 = a/b*c mit e2 = a/b*d. In der Tat, ein paar erkennen das und führen a/b nur einmal aus, aber bei einem for (i = 0; i <= strlen(searchstring); i++) kann auch der beste Optimierer nichts mehr machen. Auf dem PC fällt das erst ins Gewicht, wenn man wirklich große Datenmengen zu bearbeiten hat, ein Controller, der von 'ner Solarzelle, einem Goldcap und einem Uhrenquarz leben muß, kann sich so einen hirnlosen Luxus nicht leisten - Profiler gibt's dort auch eher selten. Derlei Beispiele gibt es übrigens noch viele mehr, wie mit ein bisserl Hirn viel Rechnerei zu sparen ist.
Beides muß im Vorfeld und bei der Erstellung präsent sein, um nicht in eine Performance- Falle zu tappen, hat aber eigentlich nichts mit Optimierung zu tun.
An Tims 0/1/-1 Beispiel sieht man deutlich, daß es was bringen kann, wenn z.B. ein Hardwaremultiplizierer fehlt. Die nötige Gegenfrage lautet, wie sehr die Vergleiche weh tun und führt uns zu der Antwort, daß wir keine Antwort darauf haben, solange wir die typische Betriebssituation nicht kennen. Und wenn man Denke auf etwas verschwendet, von dem man nicht weiß, ob es überhaupt was bringt, dann ist das der klassische Fall von "premature optimization".
Ein sauberes Systemdesign und das "Performancekeeper- Bing" im Hinterkopf sind wichtiger, als sich im Vorfeld über sowas einen Kopf zu machen.
