Software Optimierung Diskussion
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Verschoben von SoftwareOptimierung
| Inhaltsverzeichnis dieser Seite | |
|
|
Persönliche Stellungnahmen | |
So pauschal halte ich nicht viel von diesen Regeln.
Es kommt immer darauf an, wer die Ursprungsquelle programmiert hat.
Ich habe schon Kode auf 40% der Ursprungsgröße optimiert.
Mindestens 95% meiner Space-Optimierungen wirken gut.
Geschwindigkeit kann allerdings meist nur durch gute Konzepte und Algorithmen
gewonnen werden.
--HelmutSchellong
Ich meine, dass die Amerikaner recht haben, solche Regeln zu deklamieren. Die Regeln sind für die, die frisch in die Programmierung einsteigen. Sie helfen ihnen, damit sie sich nicht verlaufen.
Für den Experten, der weiß was er tut, gelten ohnehin keine Regeln mehr.
Wer optimiert, muss wissen, was er tut.
-- HelmutLeitner
Meine persönliche Regel lautet: Optimiere nicht, aber...
...berücksichtige bei allem was du programmierst die auftretenden Komplexitäten.
Beispiele:
- Eine C++-Methode inline zu machen ist in diesem Sinne Optimierung.
- Unterstellt man, dass Methode std::vector<T>::size() mit Komplexität O(n)
- realisiert wurde, so ist die Verwendung von
- size() == 0 oder size() == 1 meist Missachtung der Komplexitäten.
-- SaschaDördelmann
Anekdote 1: Ein Programmierer lieferte mir Code, in dem sich folgendes Muster häufiger wiederholte:
| lpszDest=dest;
lpszSource=source;
while(*lpszSource) {
*lpszDest++=*lpszSource++;
}
*lpszDest='\0'; |
|
|
Auf meine Frage, warum er denn nicht
schreibe, sagte er: Erstens sei es schneller, zweitens sei er das schon so gewohnt!
Anmerkung: strcpy ist meist wie der Bruder memcpy eine hochoptimierte Assembler version, hoffentlich auch inlined. --ReiniUrban
Anekdote 2: Eine Programmiererin liefert mir den Code für ein Utility-Programm mit einer größeren Anzahl von globalen Flags (ca. 20). Alles ist ok, die Flags enthalten die Einstellungen, ob der Benutzer Groß/Kleinschreibung unterscheiden will etc. Allerdings hat sie die 20 Flags als Bits in zwei Integer-Variablen verpackt und sie im Programm jeweils (an ca. 100 Stellen) ausgelesen:
| if(iFlag & FLAG_UPPERCASE) {
...
} |
|
|
Auf meine Frage, warum sie denn nicht
| char flag_uppercase;
if(flag_uppercase) {
...
} |
|
|
verwende, meinte sie, dass ihre Methode ja viel Platz spare. Nach der Umstellung auf die Variante 2 war sie verwundert, dass das Programm deutlich kleiner war als zuvor.
Diskussion | |
Also, für wahrhaftige Anfänger würde ich auch keine Optimierungsanstrengungen vorschlagen.
Die sollen ihr Problem erstmal formulieren und über die Klippe der Compiler-Meldungen bringen.
Ich stelle mal die These auf, daß Lesen und Probieren und Lernen besonders am Anfang eine ganz wichtige Optimierungsmaßnahme ist.
Man muß möglichst intensiv das Ziel verfolgen, die Programmiersprache voll ausschöpfen zu können, und man muß Informationen über die Libraries und die restliche Entwicklungsumgebung tanken.
Wenn das getan wurde, kann man bei jedem Problem schnell und treffsicher einen Ansatz aus dem Köcher ziehen.
Genau das wird -heutzutage- zu wenig getan!
Man probiert planlos, hektisch und enorm umständlich herum, man denkt zu wenig,
hat keine Ausdauer.
--HelmutSchellong
Deshalb sollte eigentlich eine interpretierte ReadEvalPrint? Umgebung (wie heißt das jetzt? RapidDevelopmentEnvironment? oder so?) wie sie etwa perl, python oder lisp bieten, für Anfänger besser geeignet sein. Das gilt auch für DebuggingStrategien?. --ReiniUrban
Verleiten nicht gerade solche Umgebungen zum planlosen herumprobieren?
Verschoben von ZenOfCodeOptimization:
- Kritische Anmerkung
- Code Optimierung lohnt sich heutzutage nur noch in ganz wenigen Situationen. Speziell Intel-PCs sind mittlerweile extrem schnell und billig, so dass die ProgrammiererZeit? im Vergleich zur ProzessorZeit? viel zu teuer ist, um sie für die Optimierung zu verschwenden.
Viele talentierte SoftwareEntwickler vergeuden wertvolle Zeit mit VorzeitigerOptimierung?. Vor jedem Versuch, etwas zu optimieren sollte man sich folgende Fragen stellen:
- Wird das Programm dadurch schwerer verständlich?
- Wieviel Zeit werde ich brauchen, bis ich einigermassen sicher sein kann, dass das optimierte Programm wieder das Gleiche tut, wie vor der Optimierung?
- Wie oft wird die optimierte Programmstelle durchlaufen werden? Wieviel Zeit wird durch die Optimierung dabei insgesamt eingespart?
Was ist das teuerste an Software? Im Allgemeinen die Wartung. Ergo: Im Allgemeinen sollte man sich darauf konzentrieren, die Wartbarkeit zu optimieren.
- Zustimmung. Ist nicht im Grunde das XP CodeRefactoring die Forderung, dass die StrukturOptimierung? Priorität haben muss?
- Nicht direkt, da CodeRefactoring eher ein allgemeineres Werkzeug ist, das man z.B. auch zur Optimierung von Performance oder Speicherbedarf benutzen kann. Es ist eher die Forderung, CodeRefactoring intensiv zu nutzen, um ein EinfachesDesign zu erreichen, die obigem Punkt Rechnung trägt.
- Mmmh, dann habe ich das schnell formuliert. Zweiter Versuch: Ist dann nicht im Grunde das XP EinfachesDesign die Forderung, dass die StrukturOptimierung? Priorität haben muss? (damit würde der alte Streit um die Optimierung für mich eine interessante Wendung bekommen: nicht "Optimierung - ja oder nein" sondern "Optimierung ja - aber Struktur hat Priorität vor Platz und Zeit"). -- hl
- Ja, genau so sehe ich das auch. -- ip
- Ich sehe es nicht so. Refactoring ist ein Werkzeug, das dazu dient, die Software so zu ändern, dass neue Anforderungen leichter implementiert werden können.
- Refactoring ist die Änderung des Designs in kleinen Schritten, ohne das externe Verhalten zu ändern. Man kann problemlos durch Refactoring das Design eines Systems verhunzen - immerhin gibt es zu quasi jedem Refactoring auch ein entgegengesetztes (z.B. MethodeExtrahieren? vs. MethodeInlinen?). Du hast allerdings recht, dass man natürlich im Allgemeinen bemüht sein sollte, das Design durch Refactoring zu verbessern...
- Ich habe das Gefühl, dass WerdenWirNichtBrauchen auch für schlechtes Design gelten sollte :-) -- gR
- So kann man es natürlich auch ausdrücken... :-)
- Umsetzung der Anforderungen bedeutet auch Änderung des Codes, ist aber kein Refactoring. Perfomance- oder Speicheroptimierung sollte man nur dann machen, wenn es dafür eine Anforderung gibt. Es gehört also in die Phase der Anforderungsumsetzung und nicht in die Phase der Refactorings.
- Wenn Du Refactoring als Phase betrachtest, gebe ich Dir recht. Wenn Du es allerdings eher als Technik ansiehst, kannst Du diese IMO auch einsetzen, um Performance- oder Speicheroptimierungen durchzuführen. Natürlich könnte man argumentieren, dass damit das externe Verhalten geändert wird, aber imho sind wir damit in einer Zwickmühle, da es schwierig sein dürfte, Refaktorisierungen zu finden, die keinerlei Einfluss auf Performance oder Speicherbedarf haben...
- Klar, wenn man Refactoring als Technik der kleinen Veränderungen sieht, dann hast Du recht. Und natürlich kann Refactoring Einfluß auf Performance und Speicherbedarf haben, genauso wie das Umsetzen der Anforderungen Einfluß auf die Struktur des Programms hat. Wenn man aber Umsetzen der Anforderungen und Refactoring als Phasen sieht, kann man sagen, dass es in den Phasen unterschiedliche Prioritäten gibt. Anforderungsimplementierung: Priorität sind die Anforderungen (dazu kann Performance gehören); Refactoring: Struktur des Programms
- Und die Struktur des Programmes sollte man auch nur dann verbessern, wenn man eine Funktionalitätsänderung vorhat, den was hat der Kunde davon, dass sein Programm besser strukturiet ist, wenn es nicht der besseren Funktionalität dient?
- Siehe GnadenlosesRefaktorisieren.
- Man kann also nicht sagen, dass bessere Struktur höhere Priorität als Performance hat, denn diese Attribute werden in unterschiedlichen Phasen der Softwareentwicklung angegangen und konkurrieren nicht miteinander. Es macht also keinen Sinn, sie zu priorisieren.
- Mein Kommentar gilt natürlich nur im ExtremeProgramming-Kontext, wo immer gilt: Habt Ihr nicht was besseres zu tun? :-) -- gR
- Sorry, aber es gilt nicht immer, sondern nur in Bezug auf Funktionalität. Siehe WerdenWirNichtBrauchen und DunklesYagni. -- ip
- weitere Diskussion verschoben nach GnadenlosesRefaktorisieren
C++ zu benutzen ist schon eine Art Optimierung, die der Compiler und Linker übernimmt.
Warum sollte eine Methode über eine vorkompilierte Tabelle gefunden werden? Warum muss der Aufrufer die Bytegröße der Strukturen kennen? Alles Optimierung.
- Und das bedeutet für alle, die nicht optimieren: Nicht C++ programmieren!
- Als jemand, der sowohl C++ als auch Smalltalk oder Ruby kennt, kann ich
- dem nur zustimmen ;-) (Sascha)
KategorieOptimierung KategorieDiskussion
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 1. April 2004 17:09 (diff))