718 kb .exe datei - nur ein Fenster ohne alles o_0
-
Pelle schrieb:
stimmt es dass C++ schneller als C ich dachte immer andersrum wegen overhead von c++ etc..
So ist es. Generell sagt man, dass C-Programme schneller sind, da es beispielsweise son Schnickschnack wie VMT's nicht gibt (Ich bevorzuge C++ trotzdem, aber das nur am Rande^^).
Pelle schrieb:
Offensichtlich besitzt C eine bessere Bibliothek für Multithreading als C++
Das ist totaler Schwachsinn, da, wenn Du WinAPI programmierst, Du sowieso die C-Implementierung der Multithreaded-Funktionen verwendest. Generell kann man das eh nicht so verallgemeinern. Des weiteren ist der Vergleich zwischen C und C++ schwierig, da C++ ja C-Code enthalten kann.
Zu Deinem Problem: Es kann, wie bereits angesprochen wurde, u.a. am statischen/dynamischen Linken liegen (wie Du ja auch schon geschrieben hast), aber auch an den Konfigurationseinstellungen des Compilers. In meiner IDE (MS Visual Studio 2005) kann man z.B. zwischen 'Debug' oder 'Release' Modus umstellen: Dies wirkt sich auch stark auf die Größe der Executeable aus
. Ferne bietet jeder Compiler meistens noch Optimierungs-Optionen (gerade bezüglich der Executeable-Größe).Edit: Frohes Neues
!
-
...kann man z.B. zwischen 'Debug' oder 'Release' Modus umstellen: Dies wirkt sich auch stark auf die Größe der Executeable aus
. Ferne bietet jeder Compiler meistens noch Optimierungs-Optionen (gerade bezüglich der Executeable-Größe).Edit: Frohes Neues
!richtig ich habe von debug auf release modus umgestellt und dann 7 kb erhalten anstatt 718 kb. Was mich nur wundert, warum hat meine .exe wenn das fenster sichtbar ist also nicht minimiert ganze 560 KB RAM-Verbrauch im task manager? 0,56 MB für 7KB Windows .exe datei??
-
Pelle schrieb:
0,56 MB für 7KB Windows .exe datei??
es gibt prinzipiell keinen zusammenhang zwischen dateigröße und speicherverbrauch. man kann ein 50 bytes großes programm in assembler schreiben, dass 1 gb arbeitsspeicher belegt. genauso kann eine exe 1 gb groß sein, aber nur einen bruchteil davon an speicher belegen.
der speicher geht in deinem fall wahrscheinlich größtenteils für die runtime library drauf, und für die ganzen dlls die eingebunden werden müssen um ein fenster zu erzeugen.
-
Das was Windows alles benötigt ist nicht wenig:
Schau Dir doch mal alleine an, wie große die DLLs sind, die Dein programm noch zusätzlich lädt (DEPENDS.EXE). Wenn Dui nicht statisch gelinkt hast kommt die CRT Runtime DLL dazu.
Dann schau Dir an wie groß der Stack initial ist.
Es wird ein Heap angelegt auch mit einer Grundgröße und die CRT benötigt da auch gleich Speicher.
Einiges an versteckten Kosten liegt z.B. in der Comctl32. die mitz einem entsprechenden XP Manifest auch geladen wird (sofern Du das Projekt mit VS-2005/2008 erzeigt hast).
Weiterer Speciher kommt hinzu für alle Programm die in Deiner Applikation Hook-Dlls installieren (etc. etc.)Was alles geladen wird kann die DEPENDS auch sagen...
Das ganze leppert sich zusammen.
-
Martin Richter schrieb:
Das was Windows alles benötigt ist nicht wenig:
Schau Dir doch mal alleine an, wie große die DLLs sind, die Dein programm noch zusätzlich lädt (DEPENDS.EXE). Wenn Dui nicht statisch gelinkt hast kommt die CRT Runtime DLL dazu.
Dann schau Dir an wie groß der Stack initial ist.
Es wird ein Heap angelegt auch mit einer Grundgröße und die CRT benötigt da auch gleich Speicher.
Einiges an versteckten Kosten liegt z.B. in der Comctl32. die mitz einem entsprechenden XP Manifest auch geladen wird (sofern Du das Projekt mit VS-2005/2008 erzeigt hast).
Weiterer Speciher kommt hinzu für alle Programm die in Deiner Applikation Hook-Dlls installieren (etc. etc.)Was alles geladen wird kann die DEPENDS auch sagen...
Das ganze leppert sich zusammen.
also ich includiere in der fenster.exe nur die windows.h datei um das fenster darzustellen. Natürlich habe ich mir die windows.h mal angeschaut und diese DAtei includiert ja weitere files... z.B. sind also alle unten aufgezählten files .dll files? sprich wenn .h dateien compiliert werden nennt man sie .dll dateien? Die ganzen includierten .h files in der windows.h sind diese dafür zuständig, dass meine 7 KB datei auf 560 ca. anschwillt? Kann ich denn aus der window.h datei nicht includes entfernen/auskommentieren die ich nicht benötige?
#include <winresrc.h>
#include <stdarg.h>
#include <windef.h>
#include <wincon.h>
#include <winbase.h>
#include <wingdi.h>
#include <winuser.h>
#include <winnls.h>
#include <winver.h>
#include <winnetwk.h>
#include <winreg.h>
#include <winsvc.h>
#include<ole2.h>
#include <winsock.h>
#include <winsock2.h>
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#include <imm.h>
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#include <shellapi.h>
#include <winperf.h>
#include <commdlg.h>
#include <winspool.h>/* windows.h - main header file for the Win32 API Written by Anders Norlander <anorland@hem2.passagen.se> This file is part of a free library for the Win32 API. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. */ #ifndef _WINDOWS_H #define _WINDOWS_H #if __GNUC__ >=3 #pragma GCC system_header #endif /* translate GCC target defines to MS equivalents. Keep this synchronized with winnt.h. */ #if defined(__i686__) && !defined(_M_IX86) #define _M_IX86 600 #elif defined(__i586__) && !defined(_M_IX86) #define _M_IX86 500 #elif defined(__i486__) && !defined(_M_IX86) #define _M_IX86 400 #elif defined(__i386__) && !defined(_M_IX86) #define _M_IX86 300 #endif #if defined(_M_IX86) && !defined(_X86_) #define _X86_ #elif defined(_M_ALPHA) && !defined(_ALPHA_) #define _ALPHA_ #elif defined(_M_PPC) && !defined(_PPC_) #define _PPC_ #elif defined(_M_MRX000) && !defined(_MIPS_) #define _MIPS_ #elif defined(_M_M68K) && !defined(_68K_) #define _68K_ #endif #ifdef RC_INVOKED /* winresrc.h includes the necessary headers */ #include <winresrc.h> #else #include <stdarg.h> #include <windef.h> #include <wincon.h> #include <winbase.h> #if !(defined NOGDI || defined _WINGDI_H) #include <wingdi.h> #endif #ifndef _WINUSER_H #include <winuser.h> #endif #ifndef _WINNLS_H #include <winnls.h> #endif #ifndef _WINVER_H #include <winver.h> #endif #ifndef _WINNETWK_H #include <winnetwk.h> #endif #ifndef _WINREG_H #include <winreg.h> #endif #ifndef _WINSVC_H #include <winsvc.h> #endif #ifndef WIN32_LEAN_AND_MEAN #include <cderr.h> #include <dde.h> #include <ddeml.h> #include <dlgs.h> #include <imm.h> #include <lzexpand.h> #include <mmsystem.h> #include <nb30.h> #include <rpc.h> #include <shellapi.h> #include <winperf.h> #ifndef NOGDI #include <commdlg.h> #include <winspool.h> #endif #if defined(Win32_Winsock) #warning "The Win32_Winsock macro name is deprecated.\ Please use __USE_W32_SOCKETS instead" #ifndef __USE_W32_SOCKETS #define __USE_W32_SOCKETS #endif #endif #if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || defined(__MSYS__) || defined(_UWIN)) #if (_WIN32_WINNT >= 0x0400) #include <winsock2.h> /* * MS likes to include mswsock.h here as well, * but that can cause undefined symbols if * winsock2.h is included before windows.h */ #else #include <winsock.h> #endif /* (_WIN32_WINNT >= 0x0400) */ #endif #ifndef NOGDI /* In older versions we disallowed COM declarations in __OBJC__ because of conflicts with @interface directive. Define _OBJC_NO_COM to keep this behaviour. */ #if !defined (_OBJC_NO_COM) #if (__GNUC__ >= 3) || defined (__WATCOMC__) #include <ole2.h> #endif #endif /* _OBJC_NO_COM */ #endif #endif /* WIN32_LEAN_AND_MEAN */ #endif /* RC_INVOKED */ #ifdef __OBJC__ /* FIXME: Not undefining BOOL here causes all BOOLs to be WINBOOL (int), but undefining it causes trouble as well if a file is included after windows.h */ #undef BOOL #endif #endif
-
Du missversehst mich. Ichmeine die DLLs die das System zwangsweise eben mit Deiner Applikation einbindet. Das hat gar nichts mit Deinen Headern zu tun.
Schau Dir doch mal bitte DEPENDS.EXE an!
Die entsprechenden DLLs, di in Deinen Speicher geladne werden sind eben da und notwendig.
Was ist Dein Problem mit 750KB oder mehr oder weniger?
-
Martin Richter schrieb:
Du missversehst mich. Ichmeine die DLLs die das System zwangsweise eben mit Deiner Applikation einbindet. Das hat gar nichts mit Deinen Headern zu tun.
Schau Dir doch mal bitte DEPENDS.EXE an!
Die entsprechenden DLLs, di in Deinen Speicher geladne werden sind eben da und notwendig.
Was ist Dein Problem mit 750KB oder mehr oder weniger?
wenn ich schon C schreibe und nicht java dafür nehme will ich kleine programme coden. Warum hast DU denn ein Problem damit, sollte doch meines sein?? Und nein asm rechtfertigt das Nutzen-/Aufwandsverhältnis nicht... Ich habe alles auf C:\ abgesucht und finde keine depends.exe im speicher ist sie auch nicht geladen, wo ist diese datei?
warum geht der server mehrmals am tag offline? Ich schreibe was wills abschicken und zapp "die site kann icht angezeigt werden" ? Das Problem habe ich nur mit dem c-++.de forum.
-
-
Ansonsten gehört DEPENDS.EXE zum Lieferumfang von VisualStudio.
Nochmal: Die Größe Deines Programmes hängt einfach auch davon ab, welche DLL's sie verwendet und welchen Speicher die einfach allokieren...
Wnen Du meinst ein JAVA Programm würde weniger Speicher weg nehmen, dann irrst Du Dich. Es ist vieleicht in der Größe der EXE kleiner. Alleridngs wird hier ja auch die ganze Runtime nachgeladen, gleiches gilt für .NET Programe.
Ganz zu Schweigen von deren dynamischen Speicherhunger.
-
Martin Richter schrieb:
Ansonsten gehört DEPENDS.EXE zum Lieferumfang von VisualStudio.
Nochmal: Die Größe Deines Programmes hängt einfach auch davon ab, welche DLL's sie verwendet und welchen Speicher die einfach allokieren...
Wnen Du meinst ein JAVA Programm würde weniger Speicher weg nehmen, dann irrst Du Dich. Es ist vieleicht in der Größe der EXE kleiner. Alleridngs wird hier ja auch die ganze Runtime nachgeladen, gleiches gilt für .NET Programe.
Ganz zu Schweigen von deren dynamischen Speicherhunger.Ich habe Visual Studio nicht, werde mir aber mal die express version laden mit dem intel compiler um vergleiche mit dem gcc zu haben. Die vergleiche basieren dann auf dem fertig programm natürlich nicht dem leeren fenster
Natürlich sind java programm so fett wegen der runtime siehe task manager java.exe etc. die eigene programm.exe ist ja extra angezeigt, wobei auch die ziemlich fett ist für einen mp3 player den ich nun in C coden möchte. es ist schon ein unterschied ob die mp3.jar 12 mb hat oder 2 mb im RAM , wenn C dann im hinblick auf größe und speed sonst kann ich gleich java nehmen.
-
Pelle schrieb:
Natürlich sind java programm so fett wegen der runtime
bei c-programmen ist das genauso "natürlich", denn auch die brauchen idR eine laufzeitbibliothek.
und "nur ein fenster ohne alles" ist auch schon eine ganze menge, was den speicherbedarf rechtfertigen kann. möglicherweise legt windows einen pixelbuffer für den inhalt deines fensters im adressraum des prozesses an, und schon sind ein paar hundert k weg. es ist eine übliche strategie, bessere geschwindigkeit durch höheren speicherverbrauch zu erlangen.
schreib dir doch einfach mal ein kleines programm, dass nichts weiter tut als
int main() { while(1); }und schau, was dabei rauskommt.
außerdem könnte es auch gut sein, dass du nun noch viele tausend zeilen code dazuschreibst ohne dass der speicherverbrauch ansteigt, weil die rtl vielleicht schon im voraus speicher reserviert (reine spekulation).
du solltest dich nicht mit optimierung deines programmes rumschlagen wenn du noch nicht mal angefangen hast zu programmieren. 700 k sind übrigens nicht wirklich beanspruchend für einen modernen computer mit windows.
-
-
-
Mich würde interessieren was du dich um die paar kB Speicher kümmerst. Also heutzutage sind die meisten Computer mit genügend RAM ausgestattet. Du hast keinen Plan für was Headerdateien benötigt werden und weist nicht wie DLLs entstehen, machst dir aber Gedanken wegen der Speicheroptimierung deiner Programme. Dann postest du einen haufern Quellcode den du nicht interpretieren kannst. Vieleicht solltest du ertmal die Grundbegriffe der Programmierung lernen.
-
Initial sind die exen vielleicht bisschen gross, allerdings wachst das Compilat ja nicht exponentiell mit
D.H. wenn du 200 Zeilen schreibst kanns vielleicht 700k haben, was aber nicht bedeutet, dass ein 400 Zeilen Programm auf einmal 1400k haben wird, sondern nur unwesentlich mehr als die 700k -> ausser du verwendest im 400 Zeilen Programm zusätzliche Bibliotheken im Vergleich zum 200 Zeilen Programm.
-
Haste Worte? schrieb:
Mich würde interessieren was du dich um die paar kB Speicher kümmerst. Also heutzutage sind die meisten Computer mit genügend RAM ausgestattet. Du hast keinen Plan für was Headerdateien benötigt werden und weist nicht wie DLLs entstehen, machst dir aber Gedanken wegen der Speicheroptimierung deiner Programme. Dann postest du einen haufern Quellcode den du nicht interpretieren kannst. Vieleicht solltest du ertmal die Grundbegriffe der Programmierung lernen.
Mich würde interessieren warum du dich dafür interessierst, was andere nicht zu interessieren hat? Wer hat denn behauptet, dass er den quellcode interpretieren muss? Es gibt genug Situation in denen man alle 4 GB RAM verrendert und nebenher anstatt eines 15 MB players 14 MB sparen möchte... nach deiner KB Aussage kann man ja gleich java nehmen...
Pelle
-
Da aber gleiche DLLs im Speicher geshared werden mit anderen Prozessen, die selben DLLs verwenden ist es manchmal besser Speicher durch gesharte große LIbs zu "verschwenden" anstatt diese durch statisches linken zu sparen!
Wenn zwei Prozesse z.B. gleichzeitig die MFC DLLs verwenden oder die gleiche CRT. Dann lohnt statisches Linken bereits nicht mehr!
Und das ist eben nicht messbar anhand der Exe Größe oder der Größe die ein Prozess braucht. Die Hintergründe sind weitaus komplexer.
