Konzept zur Leistungsoptimierung von C++-Programmen
- Art: Diplomarbeit
- Autor: Klaus Erlenbach
- Abgabedatum: September 2003
- Umfang: 64 Seiten
- Dateigröße: 998,6 KB
- Note: 1,5
- Institution / Hochschule: Private FernFachhochschule Darmstadt Deutschland
- Bibliografie: ca. 27
- ISBN (eBook): 978-3-8366-1461-0
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Erlenbach, Klaus September 2003: Konzept zur Leistungsoptimierung von C++-Programmen, Hamburg: Diplomica Verlag
- Schlagworte: Leistungsoptimierung, Performance, Programm, C++, Entwicklungsprozess
38,00 €
PDF-eBook Download: 38,00 €
Diplomarbeit von Klaus Erlenbach
Einleitung:
Im Rahmen dieser Diplomarbeit soll untersucht werden, wie der Entwicklungsaufwand für eine nachträgliche Leistungsoptimierung von bereits bestehenden C++-Programmen reduziert werden kann. Mit dem zu entwickelnden Konzept soll sowohl die Effizienz als auch die Wirtschaftlichkeit der Software-Entwicklung im Unternehmen verbessert werden.
Dies soll am Beispiel von Programmen der Firma 3D-SHAPE GmbH in Erlangen untersucht werden. Die Firma entwickelt und vermarktet optische Sensoren für berührungslose, 3-dimensionale Formvermessung und Software zur Verarbeitung, Analyse und Bearbeitung der 3-dimensionalen Messdaten.
Um die großen Mengen an Messdaten in akzeptabler Zeit zu verarbeiten, sind hoch optimierte Software-Algorithmen erforderlich.
Die Untersuchungen zur nachträglichen Software-Optimierung sind notwendig, da in vielen Software-Projekten ein Trend zur „Leistungsoptimierung im Nachhinein“ zu beobachten ist. Die dabei entstehenden Entwicklungskosten sind hier jedoch wesentlich höher als wenn dieser Aspekt bereits in der Anfangsphase der Entwicklung eines Software-Produktes behandelt worden wäre.
Oft stehen jedoch die vollständige Erfüllung der funktionalen und qualitativen Anforderung sowie die termingerechte Auslieferung der Software im Vordergrund. Erst dann, wenn die Rechner-Hardware die Leistungsanforderungen der Software nicht erfüllen kann, werden in der Wartungs- und Pflegephase des Software-Entwicklungsprozesses eventuell vorhandene Leistungsdefizite durch Maßnahmen zur Leistungsoptimierung beseitigt. Auf diese Weise erhofft man sich im Allgemeinen das Risiko einer Terminüberschreitung zu reduzieren und unnötigen Optimierungsaufwand einzusparen.
Obwohl das Thema durch den sich abzeichnenden Trend aktuell ist, ist mir keine Literaturstelle bekannt, die ein Konzept anbietet, um den Aufwand einer Leistungsoptimierung in der Wartungs- und Pflegephase eines Software-Projektes zu reduzieren.
Das in dieser Diplomarbeit zu entwickelnde Konzept zur Leistungsoptimierung soll diese Lücke - zumindest teilweise - schließen und dem Software-Entwickler helfen, diese Aufgabe möglichst effizient durchzuführen.
Im Rahmen dieser Arbeit werden daher folgende Tätigkeiten durchgeführt:
Analysieren jener Prozesse, die im Rahmen eines Entwicklungsprojektes für die nachträgliche Optimierung eines Software-Produktes anfallen.
Entwerfen eines Konzeptes, um mit Hilfe eines Optimierungskataloges den Aufwand für die „Leistungsoptimierung im Nachhinein“ zu reduzieren.
Erstellen eines erweiterbaren Optimierungskataloges, der in der Basisversion allgemeine Optimierungsbausteine enthält, die dem Entwickler bei derDurchführung einer Optimierungsaufgabe behilflich sind.
Anhand einer konkreten Aufgabenstellung zeigen, wie das Konzept zur „Leistungsoptimierung im Nachhinein“ mit Hilfe des Optimierungskataloges in der Praxis umgesetzt wird.
Aufgrund der umfangreichen Thematik sowie einer konkreten Aufgabenstellung bei der 3D-Shape GmbH in Erlangen, beschränken sich die Untersuchungen rein auf die nachträgliche Leistungsoptimierung von C++-Programmen, die unter einem Windows-Betriebssystem von Microsoft auf Rechnern mit Prozessoren der Firma Intel laufen. Das Konzept ist jedoch ohne Probleme auch auf andere Programmiersprachen und Plattformen übertragbar.
Inhaltsverzeichnis:
| 1. | Einleitung | 1 |
| 2. | Theoretische Grundlagen | 3 |
| 2.1 | Entwicklungsphasen eines Software-Projektes | 4 |
| 2.1.1 | Die Planungsphase | 4 |
| 2.1.2 | Die Definitionsphase | 5 |
| 2.1.3 | Die Entwurfsphase | 5 |
| 2.1.4 | Die Implementierungsphase | 6 |
| 2.1.5 | Die Abnahme- und Einführungsphase | 6 |
| 2.1.6 | Die Wartungs- und Pflegephase | 6 |
| 2.2 | Software-Teststrategien | 7 |
| 2.2.1 | Dynamische Tests | 7 |
| 2.2.1.1 | Diversifizierende Tests | 8 |
| 2.2.1.2 | Systemtests | 9 |
| 2.2.2 | Statische Tests | 9 |
| 2.3 | Analyse von Algorithmen | 10 |
| 2.3.1 | Empirische Methode zur Analyse von Algorithmen | 10 |
| 2.3.2 | Mathematische Methode zur Analyse von Algorithmen | 11 |
| 2.4 | Bausteinbasierte Software-Entwicklung | 12 |
| 3. | „Leistungsoptimierung im Nachhinein“ | 14 |
| 3.1 | Notwendigkeit einer Leistungsoptimierung | 15 |
| 3.2 | Gründe für eine „Leistungsoptimierung im Nachhinein“ | 16 |
| 3.2.1 | Abschätzungsrisiken vermeiden | 16 |
| 3.2.2 | Rechengeschwindigkeit der Hardware nutzen | 16 |
| 3.3 | Verbesserung der „Leistungsoptimierung im Nachhinein“ | 17 |
| 4. | Prozess zur „Leistungsoptimierung im Nachhinein“ | 18 |
| 4.1 | Planungsphase | 20 |
| 4.1.1 | Funktionsanalyse durchführen | 20 |
| 4.1.2 | Leistungsziel festlegen | 21 |
| 4.1.3 | Lastenheft erstellen | 22 |
| 4.1.4 | Entwicklungsaufwand abschätzen | 22 |
| 4.2 | Definitionsphase | 23 |
| 4.2.1 | Produktumgebung festlegen | 24 |
| 4.2.2 | Anforderungen spezifizieren | 24 |
| 4.2.3 | Pflichtenheft erstellen | 25 |
| 4.3 | Vorbereitungsphase | 25 |
| 4.3.1 | Quellcode ermitteln | 26 |
| 4.3.2 | Testumgebung festlegen | 27 |
| 4.3.3 | Testdaten generieren | 27 |
| 4.3.4 | Regressionstest durchführen | 28 |
| 4.3.5 | Zeitmessmethode festlegen | 28 |
| 4.3.6 | Benchmark-Messung durchführen | 29 |
| 4.4 | Optimierungsphase | 29 |
| 4.4.1 | Performance-Analyse durchführen | 31 |
| 4.4.1.1 | Die Methode „Inspektion“ | 31 |
| 4.4.1.2 | Die Methode „Mathematische Analyse“ | 32 |
| 4.4.1.3 | Die Methode „Performance-Messung“ | 32 |
| 4.4.2 | Optimierungen implementieren | 33 |
| 4.4.3 | Regressionstest durchführen | 33 |
| 4.4.4 | Ergebnisse vergleichen | 34 |
| 4.4.5 | Fehler korrigieren | 34 |
| 4.4.6 | Benchmark-Messung durchführen | 34 |
| 4.4.7 | Messergebnisse vergleichen | 35 |
| 4.4.8 | Abbruchkriterium prüfen | 35 |
| 4.5 | Abschlussphase | 36 |
| 4.5.1 | Hilfsfunktionen entfernen | 36 |
| 4.5.2 | Systemtest durchführen | 37 |
| 4.5.3 | Produkt freigeben | 37 |
| 5. | Konzept zur „Leistungsoptimierung im Nachhinein“ | 38 |
| 5.1 | Grundidee | 38 |
| 5.2 | Grundprinzip eines Optimierungskataloges | 39 |
| 6. | Entwicklung eines Optimierungskataloges | 40 |
| 6.1 | Anforderungen an einen Optimierungskatalog | 40 |
| 6.1.1 | Geeignete Darstellungsform | 40 |
| 6.1.2 | Thematische Gliederung | 40 |
| 6.1.3 | Einheitliche Namenskonvention | 41 |
| 6.1.4 | Ausführliche Dokumentation | 41 |
| 6.1.5 | Versionisierung der Optimierungsbausteine | 42 |
| 6.1.6 | Erweiterbarkeit | 43 |
| 6.2 | Realisierung eines Optimierungskataloges | 43 |
| 6.2.1 | Produktbeschreibung | 43 |
| 6.2.2 | Dateiformate | 43 |
| 6.2.3 | Namenskonventionen | 44 |
| 6.2.4 | Optimierungsbausteine | 44 |
| 6.2.5 | Aufbau des Optimierungskataloges | 45 |
| 7. | Fallbeispiel: Einsatz des Optimierungskataloges | 46 |
| 7.1 | Aufgabenstellung | 46 |
| 7.2 | Projektdurchführung | 46 |
| 8. | Resümee | 50 |
| 8.1 | Rückblick | 50 |
| 8.2 | Ergebnisse | 51 |
| 8.3 | Konsequenzen | 52 |
| 8.4 | Ausblicke | 53 |
Textprobe:
Kapitel 3., Leistungsoptimierung im Nachhinein:
Das Optimieren der Ausführungsgeschwindigkeit eines Software-Produktes am Ende eines Entwicklungsprojektes oder gar erst nach Freigabe und Auslieferung in der Wartungs- und Pflegephase ist bekanntermaßen sehr zeitaufwendig und teuer. Im Allgemeinen wird davon ausgegangen, dass die Kosten für Änderungen mit dem Projektfortschritt exponentiell steigen.
Trotzdem kann man in konkreten Software-Projekten immer wieder beobachten, dass solche Optimierungsaufgaben an das Ende eines Software-Entwicklungsprojektes gestellt werden. In einem Artikel der Zeitschrift IEEE Software wurde bereits vor über zehn Jahren auf diese Problematik aufmerksam gemacht: „Fixing it later was a viable approach in the 1970s, but today it is dangerous. Performance-Engineering methods fall between the extremes of ‘performance-driven development’ and ‘fixing it later’”.
Dass diese Problematik mehr als zehn Jahre später immer noch aktuell ist, belegt die folgende Aussage aus dem Fachartikel:
„Examining performance at the end of software development is a common industrial practice, but it can lead to using more expensive and powerful hardware than originally proposed, time-consuming tuning measures, or (in extreme cases) completely redesigning the application…. To avoid such costs, a system’s performance characteristics must be considered throughout the whole software development process”.
Notwendigkeit einer Leistungsoptimierung:
Trotz ständig steigender Rechenleistung der Hardware ist eine Leistungsoptimierung von Software-Produkten oftmals unumgänglich. Wie die folgenden Beispiele zeigen, machen es die aktuellen Anforderungen an die Rechengeschwindigkeit und die zu verarbeitende Datenmengen nach wie vor erforderlich, dass die Ressource „Hardware“ von der Software möglichst effizient genutzt wird.
Multimedia-Applikationen:
Bilddaten sollen möglichst 3-dimensional sein und eine möglichst große und realistische Auflösung mit immer mehr Farben besitzen. Bewegte Bilder sind schon fast selbstverständlich. Solche Anforderungen sind selbst mit den neuesten Rechnergenerationen nur dann zu erfüllen, wenn effiziente Algorithmen eingesetzt werden.
Datenbanken:
In Datenbanken steigt die Menge der zu verwaltenden Daten drastisch an. Immer mehr Informationen werden gesammelt. Dies erfordert auch immer komplexere Auswertungen, deren Ergebnisse dennoch möglichst sofort verfügbar sein sollen.
Hardware-Geschwindigkeit:
Die Hardware wird immer schneller und liefert immer größere Mengen an Daten. So steigt nicht nur die Datenmenge selbst, sondern auch die Zeit wird immer kürzer, in der die Daten verarbeitet werden müssen.
Betriebssystem:
In einer Multitasking-Umgebung belegen gleichzeitig mehrere Programme einen Teil der verfügbaren Gesamtrechenleistung eines Rechners. Auch die Anforderungen an diese Programme werden immer komplexer. Dennoch erwartet der Anwender, dass er von der Ressourcen-Aufteilung möglichst nichts bemerkt und alle Programme scheinbar „gleichzeitig“ ablaufen.
Weitere Beispiele finden sich bei [Joh98, S.280] in dem Artikel „High-Speed, Wide Area, Data Intensive Computing: A Ten Year Retrospective”.
Gründe für eine „Leistungsoptimierung im Nachhinein“:
- Der Trend, eine Leistungsoptimierung erst am Ende oder nach der Freigabe eines Software-Projektes durchzuführen, hat sich aus verschiedenen Motiven heraus entwickelt. Zwei davon werden im Folgenden vorgestellt.
- Abschätzungsrisiken vermeiden.
Die Projektleitung hat die Aufgabe, die Software termingerecht zu den geplanten Kosten und in der geplanten Qualität auszuliefern [Brö00, S.291]. Der notwendige Zeitaufwand für die Entwicklung einer leistungsoptimierten Software ist jedoch sehr schwer abzuschätzen.
Durch die Strategie der „Leistungsoptimierung im Nachhinein“ hofft man nun, das Risiko einer Terminüberschreitung zu reduzieren. Erst nachdem die Entwicklung der Funktionalität eines Software-Produktes abgeschlossen ist, wird die restliche zur Verfügung stehende Projektzeit genutzt, um Optimierungsmaßnahmen durchzuführen. Fehlt diese Zeit, dann wird die Optimierung häufig erst nach Freigabe der Software in der Wartungs- und Pflegephase des Software-Produktes durchgeführt.
- Rechengeschwindigkeit der Hardware nutzen Gordon Moore (ehem. Gründer und CEO von Intel®) hat 1965 die Prognose aufgestellt, dass sich die Transistordichte integrierter Schaltkreise alle 18 Monate verdoppelt. Entsprechend erhöht sich auch die Leistungsfähigkeit von Mikroprozessoren. Diese durch die Medien als „Mooresches Gesetz“ bekannt gewordene Prognose hat bis heute seine Gültigkeit bewahrheitet und wird dies nach Einschätzung von Moore selbst auch für die nächsten zehn Jahre noch tun.
Bei der Strategie der „Leistungsoptimierung im Nachhinein“ beginnt man mit den Leistungstests erst am Ende der Software-Entwicklung, um dann (unter Einsatz aktueller Hardware) eventuell noch vorhandene Leistungsdefizite aufzuspüren und durch Software-Optimierung zu beseitigen.
38,00 €
PDF-eBook Download: 38,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783836614610
Arbeit zitieren:
Erlenbach, Klaus September 2003: Konzept zur Leistungsoptimierung von C++-Programmen, Hamburg: Diplomica Verlag
Schlagworte:
Leistungsoptimierung, Performance, Programm, C++, Entwicklungsprozess



