Das Performance-Handbuch: Ausführbare Anwendungen

Dieser Teil beschäftigt sich mit einem weiteren Teil der Anwendungsentwicklung – der Erstellung der Auslieferungsversion. Es werden in diesen Abschnitt eine große Anzahl von Möglichkeiten dargestellt, die nicht alle für die von Ihnen gewählte Programmiersprache verfügbar sein müssen.

Interpretersprachen

Für Interpretersprachen ist die einfachste Art den Interpreter aufzurufen. Dabei kann über eine einfache Batch-Datei der Interpreter mit den entsprechenden Parametern aufgerufen werden. Dieses Vorgehen kann z.B. in Java, Perl oder auch Basic genutzt werden.

Wrapper

Eine Möglichkeit, eine ausführbare Anwendung zu erstellen ist das Umschließen (Wrappen) der Anwendung durch eine für das Betriebssystem ausführbare Anwendung.

Java

Für Ihre Java Anwendung stehen Ihnen hierbei verschiedene Möglichkeiten zur Verfügung. Neben der Variante Ihre Klassen als eine Sammlung von *.class Dateien auszuliefern, können Sie diese auch in einer Java Archiv Datei [JAR] zusammenfassen. Dies ist eine per zip komprimierte Datei, welche noch einige Metainformationen zur Verfügung stellt. Um diese zu starten reicht ab dem JRE bereits der Aufruf dieser Datei aus. Voraussetzung ist jedoch, dass im System die entsprechenden Einstellungen vorgenommen wurden und ein JRE auf dem System vorliegt. Der Vorteil liegt in der möglichen Verkleinerung des Speicherplatzes. So können Sie den benötigten Festplattenplatz verringern, indem Sie die Packrate der Archivdatei erhöhen – mit dem entsprechenden Zeitnachteil beim Entpacken und Starten.

Die zweite Möglichkeit ist eine ausführbare Anwendung als Wrapper zu verwenden. Hierbei wird z.B. unter Windows eine *.exe Datei erstellt, die lediglich die JRE mit allen benötigten Parametern aufruft. Die Executable Files [EXE] nehmen dabei kaum Platz ein, können jedoch durch Verwendung entsprechender Icons optisch aufpoliert werden. Diese Variante kann mit den Java Archiv Dateien kombiniert werden. Sie müssen daher nicht nur Ihre Anwendung ausliefern, sondern auch für das Vorliegen der JRE sorgen.

Compiler

Viele Sprachen bieten auch Compiler – meist zusammen mit dem Linker – an, um ausführbare Anwendungen zu erstellen. Während in Java und .net normalerweise ein Zwischencode erstellt wird, können Sie in Assembler, C, C++, Cobol, etc. ausführbare Dateien erstellen. Auch hierbei können Sie Geschwindigkeits- und Speicheroptimierungsbetrachtungen einbringen.

Ein Compiler erstellt normalerweise erst einen Objektcode, welchen dann durch den Linker in eine ausführbare Datei oder auch in eine Library o.ä. zusammengeführt wird. Compilieren und Linken können jedoch auch gleichzeitig vorgenommen werden, ohne dass Sie etwas davon mitbekommen.

Linken

Hier sind Sie natürliche abhängig von dem verwendeten Linker. Was bedeutet Linken? Am Beispiel Cobol unter Windows:

DLLs in Windows / Shared Object unter Linux

Dynamic Link Libraries werden in Windows normalerweise genau dann geladen, wenn Sie benötigt werden und belegen dann solange Speicherplatzressourcen, wie Sie im Speicher bleiben. Meist bleiben diese solange im Speicher bis der knapp wird oder Sie die Bibliotheken explizit entladen. Für shared objects gilt prinzipiell das gleiche.

Hierfür werden die durch den Compiler entstehenden Objektdateien zu einer Bibliothek gelinkt.

Static Link

Wenn Sie einen Quelltext bauen entsteht eine Objektdatei (*.obj). Sie können nun viele dieser Objektdateien zu einer ausführbaren Datei (*.exe) zusammen linken. Beim statischen Linken muss jedoch das Runtime System zusätzlich eingebunden werden. Als Ergebnis erhalten Sie eine ausführbare Datei, die relativ groß ist.

Der Nachteil ist, dass Sie bei jeder gelinkten Anwendung die komplette Runtime Umgebung mit einbinden, wodurch mehr Speicherplatz auf der Festplatte benötigt wird. Hinzu kommt, dass mehrmaliges Starten Ihrer Anwendung auch dazu führt, dass die Runtime Umgebung mehrmals im System vorliegt. Beim statischen Linken kann die Runtime nur innerhalb eines Prozesses / Task verwendet werden.

Shared Link

Der sogenannte Shared Link ermöglicht Ihnen ebenfalls eine ausführbare Datei zu erstellen. Dabei enthält Ihre Anwendung dann jedoch nicht die Runtime Umgebung sondern nur ein Lademodul für diese. Die Runtime Umgebung hingegen wird in einer externen DLL ausgeliefert.

Bei dieser Art des Linken wird festgelegt, dass Ihre Anwendung genau diese Runtime erwartet. Das hat den Vorteil, dass die Runtime DLL nur einmal auf der Festplatte und im Speicher für viele Ihrer Anwendungen liegen muss. Wenn Sie eine weitere Anwendung starten, prüft diese zuerst ob die benötigte Runtime DLL bereits geladen ist und verwendet diese ggf. Ist dies nicht der Fall wird die benötigte Runtime nachgeladen. Das spart Festplattenkapazität und Speicherplatz.

Shared Dynamic Link

Diese Variante des Linken („Multiple Vendor Support“) entspricht weitestgehend dem Shared Link. Der Unterschied beim Shared Dynamic Link ist, dass Ihre Anwendung nicht mehr die Runtime in einer bestimmten Version anfordert, sondern diese in irgendeiner Version möchte.

Dies ermöglicht Ihnen sehr kleine Anwendungen auszuliefern. Da jede Runtime Umgebung genutzt werden kann, lädt Ihr System nur dann diese nach, wenn nicht bereits eine beliebige Version im Speicher vorliegt. Ein wesentlicher Nachteil kann hier jedoch bei Inkompatibilitäten der einzelnen Runtime Umgebungen liegen.

DLLs erstellen

Sowohl beim statischen als auch beim Shared Link haben Sie noch die Möglichkeit einzelne Objekte in DLLs auszulagern. Die kleinste Anwendung, insbesondere in Bezug auf den benötigten Hauptspeicher, beinhaltet daher lediglich ein aufrufendes Programm („Trigger“), welches noch den einen Runtime Lader beinhaltet und shared dynamic gelinkt wurde, wobei jede Objektdatei in eine einzelne DLL ausgelagert wurde. Dies kann natürlich zu dem zeitlichen Nachteil des „immer wieder eine neue DLL in den Speicher ladens“ führen.

Zurück zu Kleine FAQ |

Hoch zu Inhaltsverzeichnis |

Vor zu Weitergehende Literatur