Donald Ervin Knuth
Kategorie Allgemein
Wer kennt ihn nicht? Er ist der Urvater/Vater oder was auch immer von TeX.
Aber warum sollte ich den Ahnen von TeX erwähnen?
Wer kennt ihn nicht? Er ist der Urvater/Vater oder was auch immer von TeX.
Aber warum sollte ich den Ahnen von TeX erwähnen?
Ganz einfach!
Dieser Donald Ervin Knuth, sagte so gegen 1974 (da war ich sieben und Deutschland wurde Weltmeister!)
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
Da ich mit ihm noch nicht bei einem Bierchen diskutiert habe, kann ich nicht sagen wie er diesen Satz interpretiert!
Meine Interpretation:
Make it right
Zuerst sollte, der Code das machen, was er sollte und bei der Implementierung sollte man sich nicht durch "performance Optimierungen" aufhalten lassen, wobei man evtl. noch nicht einmal weiß, ob es ein Problem wird.
Make it fast, when necessary
Wenn der Code, dann mal rennt, sollte man die Performance nur dann verbessern, wenn es auch einen Nutzen hat. Beispiel: Warum sollte ich eine Funktion, welche einmal im Jahr aufgerufen wird und eine Laufzeit von ca. 30 Minuten hat, so verbessern, dass Sie nur noch 15 Minuten dauert? Wenn ich davon ausgehe, dass Implementierung, Tests und Deployment 1 PT dauern, heißt dies doch, dass ich nur von der investierten Zeit einen ROI nach 8 * 4 = 32 Jahren habe... Wenn das Programm, dann noch im Einsatz ist
Gruß JJR
Dieser Donald Ervin Knuth, sagte so gegen 1974 (da war ich sieben und Deutschland wurde Weltmeister!)
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
Da ich mit ihm noch nicht bei einem Bierchen diskutiert habe, kann ich nicht sagen wie er diesen Satz interpretiert!
Meine Interpretation:
Make it right
Zuerst sollte, der Code das machen, was er sollte und bei der Implementierung sollte man sich nicht durch "performance Optimierungen" aufhalten lassen, wobei man evtl. noch nicht einmal weiß, ob es ein Problem wird.
Make it fast, when necessary
Wenn der Code, dann mal rennt, sollte man die Performance nur dann verbessern, wenn es auch einen Nutzen hat. Beispiel: Warum sollte ich eine Funktion, welche einmal im Jahr aufgerufen wird und eine Laufzeit von ca. 30 Minuten hat, so verbessern, dass Sie nur noch 15 Minuten dauert? Wenn ich davon ausgehe, dass Implementierung, Tests und Deployment 1 PT dauern, heißt dies doch, dass ich nur von der investierten Zeit einen ROI nach 8 * 4 = 32 Jahren habe... Wenn das Programm, dann noch im Einsatz ist
Gruß JJR
| Permalink | 
