Statische Verknüpfung vs. dynamische Verknüpfung

Question

Gibt es zwingende Leistungsgründe, die in bestimmten Situationen dafür sprechen, statisches Linking dem dynamischen Linking vorzuziehen oder umgekehrt? Ich habe Folgendes gehört oder gelesen, aber ich weiß nicht genug über das Thema, um mich für seine Richtigkeit zu verbürgen.

1) Der Unterschied in der Laufzeitleistung zwischen statischem Linking und dynamischem Linking ist in der Regel vernachlässigbar.

2) (1) trifft nicht zu, wenn ein profilierender Compiler verwendet wird, der Profildaten zur Optimierung von Programm-Hotpaths verwendet, da der Compiler beim statischen Linken sowohl Ihren Code als auch den Code der Bibliothek optimieren kann. Beim dynamischen Linking kann nur Ihr Code optimiert werden. Wenn die meiste Zeit mit der Ausführung von Bibliothekscode verbracht wird, kann dies einen großen Unterschied ausmachen. Ansonsten gilt immer noch (1).

Answer 1

Auf Unix-ähnlichen Systemen kann dynamisches Linking das Leben von 'Root' erschweren, wenn eine Anwendung mit gemeinsam genutzten Bibliotheken an abgelegenen Orten installiert ist. Das liegt daran, dass der dynamische Linker im Allgemeinen nicht auf LD_LIBRARY_PATH oder dessen Äquivalent für Prozesse mit Root-Rechten achtet. Manchmal rettet dann statisches Linken den Tag.

Alternativ muss der Installationsprozess die Bibliotheken finden, aber das kann es schwierig machen, dass mehrere Versionen der Software auf dem Rechner koexistieren.

Answer 2

Ein weiteres Thema, das noch nicht diskutiert wurde, ist die Behebung von Fehlern in der Bibliothek.

Bei statischer Verknüpfung müssen Sie nicht nur die Bibliothek neu erstellen, sondern auch die ausführbare Datei neu verknüpfen und verteilen. Wenn die Bibliothek nur in einer ausführbaren Datei verwendet wird, ist dies möglicherweise kein Problem. Je mehr ausführbare Dateien jedoch neu verknüpft und verteilt werden müssen, desto größer ist das Problem.

Bei der dynamischen Verknüpfung müssen Sie nur die dynamische Bibliothek neu erstellen und verteilen, und schon sind Sie fertig.

Answer 3

Beim statischen Linken werden die Dateien, die das Programm benötigt, in einer einzigen ausführbaren Datei zusammengefasst.

Dynamisches Linken ist das, was man als das Übliche bezeichnen würde. Es erstellt eine ausführbare Datei, die aber dennoch erfordert, dass DLLs und dergleichen im selben Verzeichnis liegen (oder die DLLs können im Systemordner liegen).

(DLL = dynamische Verbindung Bibliothek)

Dynamisch verknüpfte ausführbare Dateien werden schneller kompiliert und sind weniger ressourcenintensiv.

Answer 4

Es gibt eine große und wachsende Zahl von Systemen, bei denen ein extremes Maß an statischer Verknüpfung enorme positive Auswirkungen auf Anwendungen und Systemleistung haben kann.

Ich beziehe mich auf die so genannten "eingebetteten Systeme", von denen viele jetzt zunehmend Allzweck-Betriebssysteme verwenden, und diese Systeme werden für alles Erdenkliche eingesetzt.

Ein sehr häufiges Beispiel sind Geräte, die GNU/Linux-Systeme mit Busybox . Ich habe das auf die Spitze getrieben mit NetBSD indem ein bootfähiges i386 (32-Bit)-Systemabbild erstellt wird, das sowohl einen Kernel als auch sein Root-Dateisystem enthält, wobei letzteres ein einzelnes statisch verlinktes (durch crunchgen ) Binärdatei mit harten Links zu allen Programmen, die ihrerseits Folgendes enthält todo (bei der letzten Zählung 274) der standardmäßigen Systemprogramme mit vollem Funktionsumfang (die meisten außer der Toolchain), und es sind weniger als 20 mega Bytes groß (und läuft wahrscheinlich sehr bequem auf einem System mit nur 64MB Speicher (sogar mit dem Root-Dateisystem unkomprimiert und komplett im RAM), obwohl ich nicht in der Lage war, ein so kleines System zu finden, um es zu testen).

In früheren Beiträgen wurde bereits erwähnt, dass die Startzeit einer statisch verknüpften Binärdatei schneller ist (und es kann eine Los schneller), aber das ist nur ein Teil des Bildes, vor allem, wenn der gesamte Objektcode in dieselbe Datei gelinkt wird, und noch mehr, wenn das Betriebssystem die Auslagerung von Code direkt aus der ausführbaren Datei unterstützt. In diesem idealen Szenario ist die Startzeit von Programmen buchstäblich vernachlässigbar, da sich fast alle Codeseiten bereits im Speicher befinden und von der Shell verwendet werden (und und und init alle anderen Hintergrundprozesse, die möglicherweise laufen), selbst wenn das angeforderte Programm seit dem Booten noch nie ausgeführt wurde, da vielleicht nur eine Seite des Speichers geladen werden muss, um die Laufzeitanforderungen des Programms zu erfüllen.

Doch das ist noch nicht alles. Ich baue und verwende normalerweise auch die NetBSD-Betriebssysteminstallationen für meine vollständigen Entwicklungssysteme, indem ich alle Binärdateien statisch verlinkt habe. Obwohl dies eine enorme Menge an Festplattenspeicher benötigt (~6,6 GB insgesamt für x86_64 mit allem, einschließlich Toolchain und X11 statisch verlinkt) (vor allem, wenn man volle Debug-Symboltabellen für alle Programme zur Verfügung hält, weitere ~2,5 GB), läuft das Ergebnis insgesamt schneller und verbraucht für einige Aufgaben sogar weniger Speicher als ein typisches dynamisch verlinktes System, das vorgibt, Bibliotheksseiten zu teilen. Festplatten sind billig (sogar schnelle Festplatten), und Speicher zum Zwischenspeichern häufig verwendeter Festplattendateien ist ebenfalls relativ billig, aber CPU-Zyklen sind es wirklich nicht, und die Zahlung der ld.so Anlaufkosten für jeden Prozess, der gestartet wird jede Die Zeit, die für das Starten eines Programms benötigt wird, nimmt stundenlang CPU-Zyklen von Aufgaben weg, die das Starten vieler Prozesse erfordern, insbesondere wenn dieselben Programme immer wieder verwendet werden, wie z.B. Compiler auf einem Entwicklungssystem. Statisch verknüpfte Toolchain-Programme können die Gesamt-OS-Multi-Architektur-Build-Zeiten für meine Systeme wie folgt reduzieren Stunden . Ich muss die Toolchain noch in meine Single einbauen. crunchgen Aber ich vermute, wenn ich das tue, wird es mehr Stunden an Bauzeit sparen, weil ich den CPU-Cache gewonnen habe.

Answer 5

Bei der statischen Verknüpfung steht Ihnen nur eine einzige Exe zur Verfügung; um eine Änderung vorzunehmen, müssen Sie Ihr gesamtes Programm neu kompilieren. Bei der dynamischen Verknüpfung hingegen müssen Sie nur die DLL ändern, und wenn Sie Ihre Exe-Datei ausführen, werden die Änderungen zur Laufzeit übernommen, was die Bereitstellung von Updates und Fehlerbehebungen durch die dynamische Verknüpfung erleichtert (z. B. Windows).