✔ [C++/VS] Dynamisch/Statisches Linken

[cwriter]

Hallo Welt

Ich stehe mal wieder auf dem Schlauch. Mein Programm ist folgendermassen aufgebaut:

Hauptprogramm          -> Lädt Plugins
         EXE        <-----------Plugins linken die Funktionen aus der Hauptdatei statisch

Nun habe ich mir überlegt, dass das ja ineffizient sein müsse, da ich die Funktionen jedes Mal für jedes Plugin neu kompilierte.
Also wäre die logische Konsequenz, die Hauptfunktionen in eine haupt-DLL auszulagern, die ich mal Core.dll nenne.
Also:

Hauptprogramm          -> Lädt Plugins
         EXE                     \
          |                       \
          V                        \
Lädt Hauptfunktionen <-----------Plugins laden Funktionen aus der Hauptdll per dllimport
   aus Core-DLL

Die Hauptdll ist damit mit v110-Compiler (VS2012) 1003kb gross, grösser, als es vorhin Hauptprogramm und plugins zusammen waren. Gut, dachte ich, das ist wohl auf die allgemeinere Definition und damit mehr Overhead zurückzuführen, aber meine Plugins (auf der Festplatte 490kb gross), blasen sich dadurch auf 10MB im RAM auf.
Mir wäre das ja egal, doch wenn ich das mit den statischen Linken vergleiche, ist das fast das Doppelte.
(Der ganze Spass übrigens im Release).
Im Debug-Mode nämlich braucht das Programm "nur" 86MB, was mit der statisch gelinkten Version vergleichbar ist, Release sind es 100MB.

Nun meine Frage: Wieso?

Gruss
cwriter

/Edit:
Nun meine Antwort: Ich habe den Output-Pfad nur bei der Debug-Version angepasst, weshalb der Releasebuild des Hauptprogrammes die Debugdll geladen hat.

 

[Cromon]

Hallo cwriter

Verwendest du nicht die Variante, dass du dein Hauptprogramn normal compilierst und dabei die für die plugins relevanten Klassen Mit dllexport kompiliert? Dadurch erhältst du eine schlanke statische lib die nicht mehr beinhaltet ausser welche Funktionen in deiner exe exportiert werden, ohne den object code derer. Das ist grundsätzlich analog zu deiner jetzigen Variante, spart aber die zusätzliche DLL.

Noch ein Wort zu der Grösse in Memory/auf Festplatte: Während eines eine gewisse Proportion gibt, darfst du nicht erwarten, dass das wirklich passt. Die ganzen Sections werden erst im RAM erstellt mit teils erheblich mehr Platz als dabei in der Datei verwendet wird. Daher ist der virtuelle Adressraum den die Sections einnehmen deutlich grösser als auf der Harddisc.

Grüsse
Cromon

 

[cwriter]

Hallo Cromon

Zuerst zur Alternative: Der Weg scheint interessant, aber welche Vorteile entstehen dadurch? Bis jetzt dachte ich immer, dass Aufteilungen in DLLs unter anderem in puncto Flexibilität eher Vor- als Nachteile bringen. Gut, eine DLL entspricht einer weiteren Read-Operation auf der Festplatte und hat wohl auch einen grösseren Overhead, aber macht das so viel aus, dass es die Vorteile (vor allem "Patch-Fähigkeit", Interoperabilität) überwiegt?
Und zum Object Code: Der wird gemäss Dependency Walker trotzdem für

::operator=()

und

::__autoclassinit()

sowie den Kon- und Destruktor erstellt (für Klassen, versteht sich).

Zum Speicherbedarf: Ja, das ist mir bewusst. Allerdings waren 10 MB doch ein bisschen viel, um als zufälliger Fehler durchzugehen
Wenn das Programm bzw. der Computer eine Weile im Idle ist, dann schrumpft der Speicherbedarf gemäss Taskmanager von 80MB auf 13MB für das gesamte Programm und ist auch durch Dateioperationen und den Einsatz speicherhungriger Texturen nicht mehr hochzukriegen. #JustWindowsThings


Gruss
cwriter