4. Memory Footprint

Memory Footprint

  • ?

    Arbeite mich seit einiger Zeit in Visual C++ Express 2008 unter Windows 7 ein.
    Habe eine einfache C-Quelldatei erstellt:

    /* uebung1.c */
#include <stdio.h>

int main(){
int a;
scanf("%d", &a);
getchar();
printf("%d", a);
getchar();
return 0;
}

    Bei den Projekteinstellungen:
    - Konsolenanwendung
    - "Release"
    - Multi-Byte Zeichensatz verwenden
    - Als C-Code kompilieren
    - Als Multithreaded DLL kompilieren /MD (also vermutlich mit msvcrt.lib (?))
    - Function Level Linking Optimierung (funktioniert das überhaupt mit /MD ?)

    So, herausgekommen ist eine ca. 8 kByte große .exe.
    Um lauffähig zu sein, muss auf meinem System laut M$ irgendwo eine msvcr80.dll vorhanden sein (allerdings ist diese msvcr80.dll in keinem der Ordner zu finden, die bei mir unter der PATH-Umgebungsvariable eingestellt sind, und diese msvcr80.dll befindet sich auch nicht im selben Ordner wie mein gerade kompiliertes Konsolen-Programm!)

    Folgende erstaunliche Dinge geschehen:

    - Obwohl Windows 7 eigentlich msvcr80.dll nicht finden dürfte, wird das Programm problemlos ausgeführt. (Gibt es noch andere Ordner, wo Windows 7 nach der msvcr80.dll sucht, außer jenen, die in PATH eingestellt sind ??)

    - So erfreulich klein meine .exe ist, so riesig ist leider (laut Task-Manager) der Speicherverbrauch, wenn das Konsolenprogramm ausgeführt wird (nämlich rund 400 kByte). Eigentlich nicht überraschend, denn es wird ja 'vom System' die msvcr80.dll in meinen Konsolenprozess 'hineingeladen' (?? was heißt das?), und je nachdem wie groß diese msvcr80.dll sein sollte, steigt dadurch wohl auch der Speicherverbrauch meines Konsolen-Prozesses.
    Aber 400 kByte Memory Footprint (zur Laufzeit) für so ein triviales Mini-Programm finde ich schon ziemlich übertrieben !
    Lädt denn Windows 7 gar die komplette msvcr80.dll in meinen Konsolen-Prozess hinein, inklusive der tausenden anderen Funktionen, die ich gar nicht aufrufe?
    Klappt dieses Funktion-Level-Linking denn nicht mit .dlls, also dass auch wirklich nur der Code jener Funktionen in meinen Konsolen-Prozess 'hineingemappt' wird, die ich auch aufrufe ?
    Habe es alternativ versucht, mit /MT zu kompilieren, aber das hilft auch nichts. Vielmehr wird dadurch nur die resultierende .exe größer (55 kB), aber der Memory Footprint meines Konsolen-Prozesses zur Laufzeit beträgt trotzdem 400 kByte.
    Kann man dieses 'Feature' von Windows 7 irgendwie austricksen, also dass triviale Mini-Programme mit ein paar Zeilen scanf und printf nicht deutlich weniger als 400 kByte im Speicher vergeuden ? Wie müsste ich denn richtiger Weise kompilieren und linken ?
    Und wie stellt es Windows 7 an, die notwendige msvcr80.dll zu finden, wo ich sie nicht einmal selber finde, wenn ich alle Ordner durchsuche, die in meiner PATH Umgebungsvariablen angeführt sind ?

    Thx für jederlei Tipps und Antworten !

    0
  • J

    SpeicherSparer schrieb:

    - Obwohl Windows 7 eigentlich msvcr80.dll nicht finden dürfte, wird das Programm problemlos ausgeführt. (Gibt es noch andere Ordner, wo Windows 7 nach der msvcr80.dll sucht, außer jenen, die in PATH eingestellt sind ??)

    Ja 😉 WinSxS... lässt Grüßen...

    SpeicherSparer schrieb:

    Lädt denn Windows 7 gar die komplette msvcr80.dll in meinen Konsolen-Prozess hinein, inklusive der tausenden anderen Funktionen, die ich gar nicht aufrufe?

    Genau 😉

    SpeicherSparer schrieb:

    Klappt dieses Funktion-Level-Linking denn nicht mit .dlls, also dass auch wirklich nur der Code jener Funktionen in meinen Konsolen-Prozess 'hineingemappt' wird, die ich auch aufrufe ?

    Soll der Linker die DLL auf Deinem Zielsystem ändern? Das geht so nicht.

    WIE hast Du denn den "Footprint" gemessen? Im TaskManager ist das die Spalte "Arbeitsspeicher (privater Arbeotssatz)".

    0
  • ?

    Jochen Kalmbach schrieb:

    WIE hast Du denn den "Footprint" gemessen? Im TaskManager ist das die Spalte "Arbeitsspeicher (privater Arbeotssatz)".

    Ja, ganz genau so hab ich es gemacht!
    Also scheinbar gibt's da keine Möglichkeit, diesen privaten Arbeitssatz für so ein Mini-Programm 'kompakter' zu gestalten.
    Und tatsächlich, im winsxs Ordner gibt's jede Menge msvcr80.dll zu finden, auch jeweils in unterschiedlichen Größen (womöglich auch inkompatiblen Versionen):
    Also wenn Windows 7 sich eine der vielen msvcr80.dll aus diesem Ordner heraussucht, kann man nur hoffen, dass dabei die 'richtige' genommen wird.
    Es ist ja unglaublich, wie oft in dem Ordner diese msvcr80.dll vorkommt (überhaupt der ganze Ordner nimmt viel zu viel Platz weg).
    Jedenfalls danke für den Tipp, habe schon (vergeblich) im System Ordner und allen Unterordnern nach 'meiner Version' von msvcr80.dll gesucht.
    Dieses Function Level Linking scheint ebenso wenig zu funktionieren, wenn ich statisch mit der msvcrt.lib linke (wonach mein Programm ja eigentlich nicht mehr von der msvcr80.dll abhängig sein sollte). Aber trotzdem verbraucht mein Konsolen-Prozess dann 400 kByte an privatem Arbeitssatz, was ich ziemlich übertrieben finde. So ein Programm mit ein paar printf und scanf Anweisungen hat doch zu DOS-Zeiten (640 kByte Maximal-Speicher) auch nicht 400 KByte belegt. Kann es sein, dass die modernen OS immer verschwenderischer mit dem Speicher umgehen ?

    0
Anmelden zum Antworten