[wxWidgets] Größe der Exe...
-
Hi,
ich wollte fragen, ob es normal ist, dass auf wxWidgets basierende Programme so riesig werden? Mein kleines Testprogramm besteht lediglich aus einem Fenster und einem Button, der "Hallo" sagt, wenn man ihn anklickt. Die Exe ist über 3 Megabyte groß! OK, die Debug-Infos sind noch drin, aber wenn ich beim Kompilieren mit Visual Studio 2005 auf Release gehe, sind es immer noch 2.7 Megabytes...wenn ich die Datei mit UPX packe, komme ich immer noch auf 850 Kilobytes.
Ist das denn wirklich notwendig? Ich meine, gibt es irgendwo eine Option, das entgültige Release möglichst klein zu packen, auch wenn das Kompilieren dann Stunden dauert, dafür aber wirklich nur die Funktionen von wxWidgets statisch implementiert werden, die auch wirklich gebraucht werden?
-
Generell muss man sagen, das wxWidgets Programme dazu tendieren, etwas größer zu sein.
Es kommt aber auch darauf an, was du linkst, und mit welchen flags die Library gelinkt wurde.
-
Der Compiler ist auch entscheidend. GCC z.B. linkt nicht benötigte Funktionen aus der Standardlibrary hinzu, was zusätzlich zur Größe des Programms beiträgt. Beim VS-Compiler liegt es wohl, wiegesagt, an den eingestellten Compilerflags. Ich weis aber nicht, ob VS alle zum Projekt hinzugelinkten Libraries auch statisch zur *.exe linkt, auch wenn manche garnicht benötigt werden. Wenn ja, dann ist es wohl wenig verwunderlich, dass die Programme so groß werden.
Kann aber auch an wxWidgets selber liegen, denn ich bekomme mit dem GCC auch riesige Programme zusammen.
-
Hi,
danke für eure Infos...
wenn ich auf Release stelle und dann noch vom Compiler die Größe optimieren lasse komme ich auf 1.17 Megabytes und nach dem Komprimieren mit UPX auf 440 Kilobytes. Naja, damit kann ich leben, wenn ich bedenke wie einfach es dadurch für mich als Programmierer wird...habt ihr denn schon Erfahrungen, wie sich wxWidgets in Bezug auf weitere Programmfunktionen Größenmäßig verhalten wird? Momentan habe ich ja nur Dialoge und führe Test-Routinen aus (algebraische Berechnungen, String-Funktionen, etc.) aber irgendwann will man ja auch mal Dateisystemfunktionen benutzen oder was mit Grafischen Elementen (Logos, Hintergründen, etc.) machen. Bekomme ich dann bei eine Standardanwendung einen 100 Megabyte-Boliden?
Gibt es hier jemanden, der mir etwas über die Größe der Exe-Dateien von den anderen Toolkits (ATL, qt, etc) verglichen mit wxWidgets sagen kann (einmal nur mit dem Compiler auf Größe optimiert und einmal mit einem ExePacker gepackt)?
-
Die Exe ist zwar bei einem Testprogramm groß, aber bedenke bitte, das dort sozusagen schon der ganze wichtige Basiscode für größere Programme drin ist. Beispiel: du hast ein Fenster instanziert. Der Code der nötigen wxFrame-Klasse ist einmalig in der Exe. Wenn du jetzt 10 weitere Fenster instanzierst, ist die wxFrame-Klasse weiterhin nur einmal in der Exe. Um so mehr du von wxWidgets nutzt, um so mehr rentiert es sich. Aber irgendwo muß ja zu Anfang der Code in der Exe da sein.
Das Argument, das dafür alles für dich als Programmierer einfacher ist, ist auch ein sehr wichtiges Argument. Wenn du eine Micro-EXE bei einem Testprogramm haben willst, mußt du WinAPI machen. ABER, da ist der Aufwand um einiges größer. Also hier gilt der Satz: man kann nicht alles haben.
-
Artchi hat Recht. Ich habe schon etwas größere Programme mit wxWidgets geschrieben, und der Unterschied beträgt -gegenüber eines kleinen Programms- maximal 0,3 MB. Ist wohl der Beweis dafür, dass der Compiler tatsächlich gleich die ganze Lib zur exe linkt. Also du brauchst keine Angst haben, dass dein Programm ein 100 MB-Bolide wird
MfG mikey.
-
Man muss auch sehen, das bei der MFC z.b. nicht statisch gelinkt wird, und deshalb
die .exe Dateien so klein sind. Auch wxWidgets kann dynamisch gelinkt werden, so
das man für verschiedene Anwendungen nur einmal die entsprechenden DLLs ausliefern muss.
-
phlox81 schrieb:
Man muss auch sehen, das bei der MFC z.b. nicht statisch gelinkt wird, und deshalb die .exe Dateien so klein sind.
Klar, weil sämtliche Klassen bzw. Methoden der MFC in DLL's ausgelagert wurden, oder?
phlox81 schrieb:
Auch wxWidgets kann dynamisch gelinkt werden, so
das man für verschiedene Anwendungen nur einmal die entsprechenden DLLs ausliefern muss.Ja und was sollte sich in den DLL's befinden? Der wxWidgets Code, der dann zur Laufzeit ausgeführt wird?
-
In den DLLs würden dann die wxWidgets Klassen stecken...
-
Hi,
Ja und was sollte sich in den DLL's befinden? Der wxWidgets Code, der dann zur Laufzeit ausgeführt wird?
Diese Form des linkens ist wohl auch eher für eine Vielzahl von wx-Projekten auf ein und demselben Rechner sinnvoll, damit nicht jede Exe die gleichen statischen Libs enthält...aber das Argument "man kann nicht alles haben" stimmt schon und ich bin mit 440 kB auch gar nicht mal so unzufrieden, wenn da schon das meiste mit drin ist.
Es würde mich nur mal interessieren, ob es bei wxWidgets oder anderen Toolkits in Kombination mit verschiedenen Compilern Pläne gibt, so eine Art optimales Funktions-Level-Linking zu betreiben, auch wenn es dabei zu erheblichen Verzögerungen beim Kompilieren kommt...dann könnte man zum Testen immer ohne Optimierung kompilieren und wenn man die finale Exe dann veröffentlichen will, lässt man den Compiler 5 Stunden rechnen und hat dafür wirklich nur die Funktionen als Maschinencode, die man auch aufruft. Das Ergebnis müsste dann doch ähnlich klein sein, als wenn ich mit Win32API programmiere und dort statisch linke (ich setze mal voraus, dass das Programm alles mitbringen sollte, um auf Maschinen von 95 bis XP autark lauffähig zu sein).
-
phlox81 schrieb:
In den DLLs würden dann die wxWidgets Klassen stecken...
Also wenn ich dich richtig verstehe, müsste man sich dann den Quelltext der jeweils benötigten wxWidgets Klassen besorgen, und diesen dann in ne DLL verpacken? Wäre aber wirklich umständlich... Bleibt aber wohl kein anderer Weg mehr offen.
-
Nein -.-
Du kannst wxWidgets als Library sowohl statisch .a/lib als auch dynamisch (.dll/.so) kompilieren.
Damit wird dann die wxWidgets Library nicht in die Exe compiliert, sondern dynamisch dazu gelinkt.
Dies ist auch notwendig, wenn man z.b. Plugins benutzen will.
-
cpphonk schrieb:
Hi,
Ja und was sollte sich in den DLL's befinden? Der wxWidgets Code, der dann zur Laufzeit ausgeführt wird?
Diese Form des linkens ist wohl auch eher für eine Vielzahl von wx-Projekten auf ein und demselben Rechner sinnvoll, damit nicht jede Exe die gleichen statischen Libs enthält...aber das Argument "man kann nicht alles haben" stimmt schon und ich bin mit 440 kB auch gar nicht mal so unzufrieden, wenn da schon das meiste mit drin ist.
Es würde mich nur mal interessieren, ob es bei wxWidgets oder anderen Toolkits in Kombination mit verschiedenen Compilern Pläne gibt, so eine Art optimales Funktions-Level-Linking zu betreiben, auch wenn es dabei zu erheblichen Verzögerungen beim Kompilieren kommt...dann könnte man zum Testen immer ohne Optimierung kompilieren und wenn man die finale Exe dann veröffentlichen will, lässt man den Compiler 5 Stunden rechnen und hat dafür wirklich nur die Funktionen als Maschinencode, die man auch aufruft. Das Ergebnis müsste dann doch ähnlich klein sein, als wenn ich mit Win32API programmiere und dort statisch linke (ich setze mal voraus, dass das Programm alles mitbringen sollte, um auf Maschinen von 95 bis XP autark lauffähig zu sein).Kurz nein.
Lang:
In deinem Win Api Programm sind auch nicht alle komponenten kompiliert, die du benutzt, da ist schon vieles bei Windows dabei, und wird
über verschiedene DLLs zur Verfügung gestellt. Auch wenn du statisch wxWidgets kompilierst, wird nicht einfach die statische Lib
in die Exe eingebunden sondern nur den Teil, den du verwendest. Zu mal die WinApi ja weitestgehend C Code und kein Objektcode von C++ ist.
wxWidgets aber ist nur Objektorientiert, und bringt auch noch den Overload eines eigenen Frameworks mit. Da ja für wxFrame nicht nur
wxFrame gelinkt wird, sondern auch alle seine Parentklassen.
-
Achso, sorry wusste ich nicht. Hm ja, ist in der Tat eine sinnvolle Alternative, bei vielen Programmmodulen.
-
soviel ich weiß kannst du die wxWidgets ja auch nur mit den Komponenten
kompilieren die du brauchst (natürlich dürfen auch hier nicht die
Abhängigkeiten der einzelnen Klassen nicht ignoriert werden )... das
spart Library-platz...
-
Um das geht's uns doch in diesem Thread
Und wie möchtest du das machen?
-
ich weiß das nur unter linux...da kann man das im konfigurations-script
angeben...(--enable-bla usw.) du kannst allerdings auch alle
Module der wxWidgets einzeln kompilieren, also jedes in eine *.lib bzw
*.dll oder *.so und es dann einzeln dazu linken statisch oder dynamisch,
statt alles monolithisch in eine library zu kompilieren...viele, viele
möglichkeiten...
-
Unter Visual C++ 6.0 habe ich wxWidgets 2.6.3 in der Eingabeaufforderung als DLL kompiliert:
- cd \Programme\Microsoft Visual Studio\VC98\bin
- vcvars32
- cd \wxWidgets-2.6.3\build\msw
- nmake -f makefile.vc BUILD=debug SHARED=1 MONOLITHIC=1 USE_XRC=1 UNICODE=0
- nmake -f makefile.vc BUILD=release SHARED=1 MONOLITHIC=1 USE_XRC=1 UNICODE=0Das Makefile makefile.vc musste ich anpassen, da der Linker ohne eine spezielle Option nur bis zu einer bestimmten Größe linkt:
Im Makefile nach " !if "(MONOLITHIC)" == "1" && "(SHARED)" == "1" " suchen und in dem 2. gefunden Abschnitt folgende Linker-Optionen verwenden:
link /DLL /NOLOGO /INCREMENTAL:NO /OUT:$@
(Die Option "/INCREMENTAL:NO" habe ich hinzugefügt)
Die Release-Version der DLL ist ca. 4,6 MB groß, und die Debug-Version ist ca. 5,5 MB groß.
Ein Test-Programm mit einem Fenster wird 64 kByte groß.