Speicherverbrauch der .exe laut Taskmanager
Das mit dem Speicherverbrauch ist doch heutzutage zweitrangig! So lange
Dein Programm Windows nicht zwingt die Auslagerungsdatei auszulasten
Wir benutzen doch kein DOS mehr wo wir gezwungen sind alles in die 640 Kb
zu quetchen!
Dein Programm Windows nicht zwingt die Auslagerungsdatei auszulasten
Wir benutzen doch kein DOS mehr wo wir gezwungen sind alles in die 640 Kb
zu quetchen!
Nein, ich habe die Suche nicht benutzt, und deshalb auch nichts dazu gefunden...
Die Größe kommt von den eingeladenen Libs (wie schon erörtert) und der mänge der benutzten Variablen/Listen/Array/ ...
An Windows gefällt mir nicht, das eine Lib für jedes Programm einzelnd in den Speicher geladen wird. Ich bendutze für extremfälle den 'TuneUp Process Manager'. Dieser zeigt mir alle geladenen DLL´s an. Da findet man die selbe DLL im selben Ordner oftmals 6-10 mal gelanden (die schlimste ist die 'kernel32.dll'. rund 20 mal gelanden).
An Windows gefällt mir nicht, das eine Lib für jedes Programm einzelnd in den Speicher geladen wird. Ich bendutze für extremfälle den 'TuneUp Process Manager'. Dieser zeigt mir alle geladenen DLL´s an. Da findet man die selbe DLL im selben Ordner oftmals 6-10 mal gelanden (die schlimste ist die 'kernel32.dll'. rund 20 mal gelanden).
Das mit dem einmal laden und 20 mal benutzt hab ich auch schon gehört!!!
Meine Frage:
Ist es möglich per windows api. z.b. ein Programm zu erzeugen, das ein unsichtbares fenster erstellt, dieses minimiert und dann maximiert, dann wäre nämlich der raumverbrauch gigantisch wenig!!! Also eben nur der wikrlich gebrauchte!! Ich fänds genial!
Meine Frage:
Ist es möglich per windows api. z.b. ein Programm zu erzeugen, das ein unsichtbares fenster erstellt, dieses minimiert und dann maximiert, dann wäre nämlich der raumverbrauch gigantisch wenig!!! Also eben nur der wikrlich gebrauchte!! Ich fänds genial!
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
-
AndyMars
- Beiträge: 141
- Registriert: 08.09.2004 11:59
- Computerausstattung: Win11 Prof 64bit, i5-13500 @ 4.8 GHz, 32GB RAM, Nvidia RTX 4070 TI
- Wohnort: Zürich, Schweiz
- Kontaktdaten:
Speicherverbrauch der .exe laut Taskmanager
Häm, häm - ist ja schon etwas alt, der Beitrag - bin halt mal wieder darüber gestolpert.
Ich habe dazu noch einige kleine Hinweise, bzw. Erklärungen gefunden:
http://www.puls200.de/?p=221
http://www.dotnetpro.de/community/newsg ... px?id=2740
Zumindest findet man da die Erklärung, weshalb sich Programme in Windows so verhalten:
Ob dieses System.GC.Collect() Objekt geeignet wäre, den Speicherverbrauch zu verkleinern, müsste jemand mit mehr Knowhow beantworten. Fragt sich, ob dieses Objekt eh nicht DotNet spezifisch ist und ob es dann eine API Entsprechung gäbe...
Jedenfalls finde ich folgenden Vergleich dazu doch sehr treffend (zumindest für mich, der davon nicht wirklich viel versteht):
Ich habe dazu noch einige kleine Hinweise, bzw. Erklärungen gefunden:
http://www.puls200.de/?p=221
http://www.dotnetpro.de/community/newsg ... px?id=2740
Zumindest findet man da die Erklärung, weshalb sich Programme in Windows so verhalten:
...und...Die Speicherverwaltung belegt bei Programmstart eine gewisse Menge virtuellen Speicher, um später schnell bei Bedarf dem Programm diesen Speicher zur Verfügung stellen zu können.
Dies sei einer der Gründe, weshalb die Angaben vom Taskmanager nur bedingt als Hinweis auf die Performance eines Programmes verwendet werden sollte...Der Speicher wird von Windows gemäß der Priorisierung allokiert. Minimiert man die Anwendung, kann man sofort sehen wie der Speicherverbrauch zurückgeht.
Ob dieses System.GC.Collect() Objekt geeignet wäre, den Speicherverbrauch zu verkleinern, müsste jemand mit mehr Knowhow beantworten. Fragt sich, ob dieses Objekt eh nicht DotNet spezifisch ist und ob es dann eine API Entsprechung gäbe...
Jedenfalls finde ich folgenden Vergleich dazu doch sehr treffend (zumindest für mich, der davon nicht wirklich viel versteht):
Finger weg von der Garbage-Collection. Du greifst dem Busfahrer doch auch nicht ins Steuer, wenn Du eine Abkürzung siehst, oder?
Grüsse von AndyMars
Ich würde mir da nicht so die Gedanken drum machen, Windows verwaltet den Speicher schon angemessen. Wenn du die Anwendung minimierst, wird das meiste ins Swapfile ausgelagert, um physikalischen Speicher für andere Anwendungen freizugeben.
Wenn das mit der Priotiät und der Speicherreservierung stimmt, dann könntest du natürlich einfach die Prozessprioriät runterschrauben. Macht aber nur Sinn für Programme, die im Hintergrund laufen sollen und möglichst wenig anderen Anwendungen im Weg sein sollen.
Btw.: PureBasic-Programme belegen wesentlich weniger Speicher als Visual Basic Programme.
Wenn das mit der Priotiät und der Speicherreservierung stimmt, dann könntest du natürlich einfach die Prozessprioriät runterschrauben. Macht aber nur Sinn für Programme, die im Hintergrund laufen sollen und möglichst wenig anderen Anwendungen im Weg sein sollen.
Btw.: PureBasic-Programme belegen wesentlich weniger Speicher als Visual Basic Programme.
Zu mir kommen behinderte Delphine um mit mir zu schwimmen.
Wir fordern mehr Aufmerksamkeit für umfallende Reissäcke!
Wir fordern mehr Aufmerksamkeit für umfallende Reissäcke!
Naja kernel32.dll enthält die LoadLibraryA funktion, welche benötigt wird um weitere DLLs zu laden, finde ich irgendwie logisch..Leonhard hat geschrieben:Die Größe kommt von den eingeladenen Libs (wie schon erörtert) und der mänge der benutzten Variablen/Listen/Array/ ...
An Windows gefällt mir nicht, das eine Lib für jedes Programm einzelnd in den Speicher geladen wird. Ich bendutze für extremfälle den 'TuneUp Process Manager'. Dieser zeigt mir alle geladenen DLL´s an. Da findet man die selbe DLL im selben Ordner oftmals 6-10 mal gelanden (die schlimste ist die 'kernel32.dll'. rund 20 mal gelanden).