nicht angemeldet
Welche Vorgehensweise ist denn hier (bei prozeduralem Code) lege artis, um gleichzeitig den Speicher zu schonen und gute Pflegbarkeit des Codes zu erreichen?
Es gibt ein paar Faustregeln der Performace- und Speicher-Optimierung:
- Tu's nicht.
- Tu's nicht... noch nicht.
- Messe, bevor du optimierst.
Du findest etliche weiterer solcher Aussagen von Informatiker*innen der ganzen Welt. Zum Beispiel dieses Zitat von Donald Knuth – einem der einflussreichsten Informatiker des letzten Jahrhunderts:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97 % of the time: pre mature optimization is the root of all evil.
Dafür gibt es gute Gründe. Performance-Engpässe konzentrieren sich meistens auf einen sehr kleinen Teil des Codes. Es ist extrem schwierig vorherzusehen, wo diese Engpässe liegen werden, selbst für sehr erfharene Entwickler*innen. Optimiert man auf Verdacht, dann ist es eher unwahrscheinlich, dass man große Erfolge erzielt, weil man im falschen Teil des Codes unterwegs ist. Deshalb sollte man messen, um den kritischen Teil des Codes ausfindig zu machen und dann gezielt optimieren zu können. Das spart Zeit und ist wesentlich effektiver als ins Blaue zu tippen. Es löst aber auch ein anderes Problem: Optimierungen haben häufig einen negativen Einfluss auf die Lesbarkeit von Code. Wenn man also ständig auf Verdacht optimiert, dann leidet die Code-Qualität darunter sehr schnell. Die Wartung des Codes wird schwieriger, zeitintensiver und teurer. Die technischen Schulden erhöhen sich rapide, dadurch sind auch die beteiligten Entwickler*innen unzufriedner und unmotivieter.
Rolf B
MudGuard
Der Martin
Henry