Eigene C-Bibliothek basteln
-
Das geht auch noch wesentlich kleiner: 688 Bytes:
http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/Die CRT verwendet intern auch nur kernel32.dll; warum solltest Du es dann nicht hinbekommen?
@neonew: boost ist keine Lösung, da diese CRT/STL vorraussetzt...
-
Außerdem werden aus der CRT nur die Funktionen gelinkt (bei statischem Binden) die man auch benutzt... Du bekommst also nur das wasDu auch verwendest!
-
Man beachte auch, dass Du *immer* mit /GS- übersetzen musst, da bei /GS einige internas von der CRT verwendet werden, die nicht dokumentiert sind!
-
Thx für den sehr lehrreichen Link!
Wenn man bedenkt, dass zu jedem Zeitpunkt unter Windows 40+ Prozesse ablaufen, die alle ihr Scheibchen Rechenzeit haben möchten (sprich: Deren Kontext pro Sekunde zigfach gespeichert und wiederhergestellt werden muss!), kann man sich leicht ausmalen, warum eine möglichst 'kleine' und problemorientierte C-Runtime zu erheblich besseren Laufzeiten führen muss als dieser 600 kB Brummer msvcrt90.dll, in den seinerseits ebensooft der 1.1 MB Brummer kernel32.dll hinein- und herausgemappt werden muss, wie der Kontext eines Prozesses für die spätere Fortsetzung gespeichert wird.
Deshalb meine Hoffnung: Eine möglichst kleine CRT müsste demzufolge zu drastisch besserer Performance führen. Mal sehen ...Entscheidende Dinge bei den Einstellungen (Visual C 2008):
(Compiler)
Erweitert -> Standardbibliotheknamen unterdrücken(Linker)
Eingabe -> NODEFAULTLIB
Zusätzliche Abhängigkeiten -> (NICHT vom übergeordneten Projekt erben!) und
nichts weiter als kernel32.lib angeben
Subsystem -> Windows
Einstiegspunkt -> mainCRTStartup (oder was auch immer man möchte)Dazu natürlich sämtliche Debug- Einstellungen, Sicherheitsüberprüfungen, C++ Ausnahmen usw. abstellen (Sollte weitestgehend bereits mit der Projekt-Konfiguration Release anstatt Debug automatisch erfolgen, aber dort, wo nicht, muss man's eben manuell tun).
Und schon hat man seinen Spaß mit den systemeigenen Dateifunktionen, und braucht sich nicht mehr mit Funktionen wie fwrite + fflush + fseek herumärgern, die ohnehin machen, was sie wollen (aber nur selten das, was man möchte).
mfg
-
Vorneweg: Um das Mapping der kernel32.dll wirst Du wohl nicht rumkommen, also spielt dieser "Brummer" hier gar keine Rolle. Bleibt also die C-Runtime. Das Mapping geht ja auch nicht schneller oder langsamer, nur weil die DLL größer oder kleiner ist. Die Anzahl der Context-Switches wird eine andere Runtime ja wohl auch nur bedingt beeinflussen.
Denkst Du denn, die MS-Runtime ist schlecht programmiert?
Es wurde jetzt bereits mehrfach erwähnt: Bei entsprechenden Einstellungen landen gar nicht die kompletten 600 KB in deinem Prozess, stattdessen landen unbenutzte Funktionen nicht mal in der exe.Ich mein, probier alles aus, ich persönlich liebe flinke Programme. Erwarte aber lieber nicht zuviel.
-
Na, ich glaube da bringst Du was durcheiander...
Was soll denn der Task-Switch mit der größe des Prozesses zu tun haben?
-
Damit hab ja nicht ich angefangen:
Wenn man bedenkt, dass zu jedem Zeitpunkt unter Windows 40+ Prozesse ablaufen, die alle ihr Scheibchen Rechenzeit haben möchten (sprich: Deren Kontext pro Sekunde zigfach gespeichert und wiederhergestellt werden muss!), kann man sich leicht ausmalen, warum eine möglichst 'kleine' und problemorientierte C-Runtime zu erheblich besseren Laufzeiten führen muss als dieser 600 kB Brummer msvcrt90.dll, in den seinerseits ebensooft der 1.1 MB Brummer kernel32.dll hinein- und herausgemappt werden muss, wie der Kontext eines Prozesses für die spätere Fortsetzung gespeichert wird.
Ich kann mir hier gar nix ausmalen. Vielleicht steh ich auch aufm Schlauch.
-
Bastler33 schrieb:
Wenn man bedenkt, dass zu jedem Zeitpunkt unter Windows 40+ Prozesse ablaufen, die alle ihr Scheibchen Rechenzeit haben möchten (sprich: Deren Kontext pro Sekunde zigfach gespeichert und wiederhergestellt werden muss!), kann man sich leicht ausmalen, warum eine möglichst 'kleine' und problemorientierte C-Runtime zu erheblich besseren Laufzeiten führen muss als dieser 600 kB Brummer msvcrt90.dll, in den seinerseits ebensooft der 1.1 MB Brummer kernel32.dll hinein- und herausgemappt werden muss, wie der Kontext eines Prozesses für die spätere Fortsetzung gespeichert wird.
Deshalb meine Hoffnung: Eine möglichst kleine CRT müsste demzufolge zu drastisch besserer Performance führen. Mal sehen ...Das führt absolut zu gar nichts. Ist Dir nicht klar, dass DLLs im Speicher geshared werden. Wenn also alle 40 Prozesse die MS-CRT sharen, dann kostet das insgesamt weniger Speicher als wenn Du Deine eigene CRT Implementierung in jeden Deiner Prozesse baust.
Ich habe DLLs mit 8MB Größe die von 6 Prozessen gleichzeotg benutzt werden. Die Prozesse selbst haben höchstens 1-2 MB. Erkennst Du den Sparfaktor.
Alles was Du da rumdoktorst ist die Zeit nicht wert.
-
Martin Richter schrieb:
Alles was Du da rumdoktorst ist die Zeit nicht wert.
Im wahrsten Sinne des Wortes
Ich rate jedenfalls auch davon ab. Als kleines Experiment für sich selber ist das natürlich okay, aber eben nicht für reale Anwendungen.
-
Ich finde es immer gut wenn Leute mal weg von der Masse einfach alles mögliche probieren. Immer davon auszugehen das alle Libs schon das optimale liefern werden ist ziemlich kurz gedacht. Um so mehr eine Lib für viele Anwendungen da ist umso mehr muss sie Kompromisse eingehen, alles was perfekt auf nur deine Anwendungen zugeschnitten ist wird schneller und resourcenschonender sein, wenn du es richtig machst.
Wenn man die Zeit und das KnowHow hat dann lohnt es sich immer selbst zu implementieren.
