Das deutsche QBasic- und FreeBASIC-Forum

[TimesChange]

Selbst wenn ich ein "Minimalprogramm"

[ALWIM]

Megabyte?

Mein unfertiges Rouletteprogramm mit ca. 1882 Zeilen Quellcode, hat gerade mal 253 KB!!!
Welchen Editor/Compiler verwendest du? Ich verwende FbEdit als Editor und den neuesten Compiler
Schon komisch irgendwie?

Verwende ebenfalls XP momentan als Betriebssystem!

Gruß
ALWIM
_________________
SHELL SHUTDOWN -s -t 05

[TimesChange]

Editor ist FBIDE.

Aber nicht dass wir aneinander vorbeireden:
Auf der Festplatte belegt das "Programm" rund 100 KB, aber bei Ausführung belegt es im Hauptspeicher ~ 3 MB (lt. Taskmanager)

Grüße
Rainer

[Jojo]

In dieser Größenordnung brauchst du dir wirklich noch keine Gedanken zu machen. Ein Großteil dieses Megabytes kommt ziemlich sicher von den DLLs, die eh von jedem Programm geladen werden. Natürlich erhält da nicht jedes Programm seine eigene Kopie der DLL im Speicher, sondern die DLL wird auf den Adressbereich deines Prozesses gemappt. Sprich, du siehst hier hauptsächlich belegten Speicher, der gar keiner ist, aber solche Infos gibt der Taskmanger halt nicht her. Mach dir lieber um den Speicherverbrauch gedanken, den dein Programm durch den von dir geschriebenen Code erzeugt.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[TimesChange]

Aber wie kann es sein, dass selbst der Windows-eigene Taskmanager mit "nur" 1,7 MB auskommt?
Und der macht sicher etwas mehr als nur einmal PRINT und SLEEP...
Irgendwie muss man da doch "runterkommen" ?

Ich gebe ja zu, dass es kein echtes Problem ist, insbesondere wenn der Taskmanager durch das Mappen von DLL's eine zu hohe Speicherbelegung anzeigt. Aber es ist jedenfalls ein massiver Schönheitsfehler für mich.

Wenn man in Zeiten knappen Speichers "aufgewachsen" ist, hält sich das eben

Grüße
Rainer

[Jojo]

Den Taskmanager kannst du schlecht mit einer GUI-Anwendung von FB vergleichen. Der "Grundverbrauch" wird beim Taskmanager ähnlich wie bei deinem Konsolenprogramm sein. Die 0,7MB mehr sind dann der ganze relevante Kram. Das sind aber halt Dinge, die du bei FB absolut nicht beeinflussen kannst.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[dreael]

Kurz bei mir einen "dir *.exe /s" übers FbEdit-Projektverzeichnis gemacht: Die typische Grösse bewegt sich so um knapp 100 KB herum bei Programmen, die mit ScreenRes ein Fenster benützen. Programme, die sich mit stdin, stdout und stderr begnügen, kommen sogar bereits mit unter 30 KB aus.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[MOD]

Es geht ihm ja nicht um die Dateigröße, sondern um den belegten RAM beim Ausführen.

Ganz einfacher Trick:
1. Öffne den Taskmanager
2. Starte dein Programm und schau dir den RAM-Verbrauch an
3. Minimiere dein Programm und schau dir den RAM-Verbrauch an
3. Stelle das Fenster deines Programms wieder her (also Klick unten auf das Programm in der Leiste) schau dir den RAM-Verbrauch an

Der Verbrauch sollte deutlich abgesunken sein und auch dabei bleiben (zumindest kann ich das so beobachten, einer der Profis wird es sicher erklären können).

[St_W]

Eine Erklärung für das Verhalten gibts z.B. auf Stackoverflow: http://stackoverflow.com/questions/3566491/memory-usage-and-minimizing
Kurz zusammengefasst: Das freigeben von Speicher (Heap) wird aufgeschoben und erst durchgeführt, wenn sonst nix zu tun is, wie z.B. wenn das Programm minimiert ist.

So schauts bei mir aus nach dem Start, nach dem Minimieren sinkts auf 148K.

_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)

[Jojo]

Der dort erwähnte "Device Loss" bei DirectX wäre z.B. auch ein heißer Kandidat, warum das beim Minimieren von FBGFX-Programmen passiert.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[TimesChange]

Das ist interessant (sowohl das Verhalten beim Minimieren, als auch die Erklärungen).

Ok, durch bestimmte Compileroptionen oder sonstiges kann ich also die Größe im Arbeitspeicher nicht so einfach beinflussen...
Oder kann ich z.B. mit der Compileroption "-t" den Stack verkleinern?
Bringt "-nodeflibs" etwas ?


Kann sich mein Programm nach dem Start zumindest selbst minimieren, und dann wieder "aktivieren" ?
Gibts dafür Windows-API-Aufrufe?

Grüße
Rainer

[Jojo]

[grindstone]

Da stimme ich Jojo voll und ganz zu.

Aber wenn du es trotzdem unbedingt versuchen willst:

[TimesChange]

Danke.
Ich gebe zu, spätestens der Schlangenöl-Hinweis hat mich überzeugt
(auch wenn ich immer noch nicht verstehe, warum mein Programm 1, 2 oder 3 MB braucht, um "hallo" zu schreiben)

Grüße
Rainer

[TimesChange]

Nochmal eine Frage in diesem Zusammenhang:

Kann ich das Erscheinen des Konsolenfensters ausschließlich durch Compilieren mit "-s gui" unterbinden?

Mir ist nämlich aufgefallen, dass der Speicherbedarf im Hauptspeicher sich etwa verdoppelt, wenn ich ein Programm mit "-s gui" compiliere.
Das Programm läuft im Grafikmodus (SCREENRES) und ist auch ohne "-s gui" voll funktionsfähig. Ich "brauche" -s gui lediglich dazu, um das Konsolenfenster verschwinden zu lassen.
Auch wenn der Win-Taskmanger nicht wirklich geeignet ist, um den exakten Speicherbedarf anzuzeigen, sieht man doch, dass hier einiges "mitgeladen" wird. Wie auch hier http://forum.qbasic.at/viewtopic.php?p=104873#104873 diskutiert, ist es sinnvoll, so wenig wie möglich zusätzlich einzubinden.

Also, gibt es noch einen anderen Weg, um das Konsolenfenster "verschwinden" zu lassen ??

Ich gebe offen zu, dass ich zu wenig davon verstehe, was bei "-s gui" im Hintergrund abläuft. Ich kann nur feststellen, dass ich etwaige weitere Funktionen durch -s gui nicht benötige, da mein Programm ja auch ohne diese Compiler-Option läuft...

Grüße
Rainer

[St_W]

Erstmal: Das "optimieren" deines Programm daraufhin, dass im Taskmanager ein möglichst kleiner Wert beim Speicher steht, halte ich für einen völlig falschen Weg das Programm zu verbessern (auch hinsichtlich Speicherverbrauch). Denn wie schon vielfach erwähnt wurde ist erstens dieser vom Taskmanager angezeigte Wert meist nicht die Speichergröße, die das Programm in Wirklichkeit gerade braucht und zweitens produzierst du durch spezielle Anpassungen hässlichen Code der oft dann erst recht einen höheren Speicherverbrauch (aber diesmal in Wirklichkeit) verschuldet. Aber aus Fehlern lernt man (hoffentlich), darum hier ein paar Infos:

In Windows gibt es mehrere Subsysteme, für die ein Programm geschrieben sein kann. Üblicherweise ist dies das Win32 Subsystem. Die Subsysteme Console und Windows (gui) würde ich als weitere Untergliederung des Win32 Subsystems bezeichnen. Die Option "-s gui" bzw. "-s console" ändert am Kompiliervorgang vom FBC soweit ich weiß gar nichts, nur beim Linken wird die entsprechende Option angegeben, sodass eine EXE für das jeweilige Subsystem erzeugt wird.
Was intern da genau intern passiert, bzw. wie sie der Loader jeweils bei einem Console/Windows Programm verhält weiß ich leider nicht und konnte ich auf die Schnelle auch nicht er-Google-n.

Eine Möglichkeit die Konsole selbst zu verstecken wird z.B. hier erwähnt: http://dcla.rkhb.de/win32/AttachConsole.html

Den Mehrverbrauch eines "-s gui"-Programmes konnte ich übrigens nicht nachvollziehen:
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)

[TimesChange]

Danke für die Infos, und für's Ausprobieren Konsole vs. GUI.
Ich verstehe schon was ihr mir sagen wollt
Und ich will mich auch nicht auf Teufel komm raus an einem nicht dafür geeigneten Instrument wie dem Taskamanger orientieren.

Nach deinem Hinweis, dass du keinen nennenswerten Unterschied beim Speicherbedarf hast, habe ich - erfolglos ! - versucht, das nochmal zu reproduzieren. (Das "Testprogramm" bei dem mir der Unterschied auffiel, habe ich nicht mehr, da ich dem keine so große Bedeutung zugemessen habe, bzw. annahm, das sei immer so). Entweder es gibt einen solchen Unterschied nur, wenn das Programm spezielle Befehle enthält, die je nach Compiler-Option einen solchen Unterschied bewirken, oder ich habe irgendeinen Unfug gemacht...


Weil ich mich gewundert habe dass dein Testprogramm nur mit <600KB angezeigt wird, habe ich nochmal einen Test mit einem hochkomplexen Programm auf Win7 gemacht:

[Jojo]

Der zugesicherte Speicher sagt absolut gar nichts darübe raus wie viel RAM dein Programm verschlingt. Der Wert könnte genau so gut für jedes offene Programm 100MB sein und dein Rechner würde noch einwandfrei laufen. Wie gesagt, mach dir über diese Werte keine Gedanken, es ist sinnlos. Da fließen Dinge mit ein, über die du keine Kontrolle hast, und wie schon erwähnt - der Wert beinhaltet Daten, die gar nicht direkt im RAM stehen bzw. die nur in den Speicher jedes Programms gemappt werden, obwohl davon genau eine Kopie im RAM liegt. Solche Dinge berücksichtigt der Task-Manager nicht und es kann auch gut sein, dass den belegten Speicher in jeder Windows-Version anders berechnet und anzeigt.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[RockTheSchock]

Wie Jojo bereits sagte mach dir über den Arbeitsspeicher keine Gedanken, da viel vom verwendeten Betriebssystem abhängt. Da spielen so viele Dinge eine Rolle. Wenn du z.B. eine Konsole aufmachst mit Start WINDOWS TASTE + R und "cmd" und dort SET eingibst siehst du die Umgebungsvariablen. Z.b. sind diese auf jedem System etwas anders und verbrauchen auch etwas Speicher wenige Bytes oder KBytes. Jedem Programm werden diese Variablen mitgegeben.

Der erstmal massgebliche Wert ist der private Arbeitssatz.
Erstmal wird die Exe Datei komplett in den Speicher geladen. Dann kommen noch spezielle Dateipuffer hinzu, Standard Eingabe/ Ausgabe / Fehlerausgabe, die vom Betriebssystem automatisch dem gestarteten Prozess zugordnet werden. Bei Grafikmodi wird automatisch ein Teil des Speichers für Grafikpuffer reserviert. Abhängig von DirectX oder GDI Treibern ist das unterschiedlich viel. Mach dir um die paar MB keine sorgen. Windows reseveirt für das Programm schon mal im voraus etwas Speicher damit das Programm schneller Speicher anfordern kann, wenn es denn welchen benötigt. (Zugesicherter Speicher)
Arbeitssatz beinhaltet Speicher der nicht nur von deinem Programm benutzt wird sondern auch von anderen Programmen geteilt wird. Das kann z.B. eine gemeinsam benutzte DLL sein.


Teste mal:
#INCLUDE "fbgfx.bi"
SCREENCONTROL FB.SET_DRIVER_NAME, "DX"
bzw.
SCREENCONTROL FB.SET_DRIVER_NAME, "GDI"

[TimesChange]

Wenn ich in mein "Hallo"-Programm den Befehl
SCREENCONTROL FB.SET_DRIVER_NAME, "GDI"
einfüge, dann wird mir eine geringere Speicherbelegung (1 MB weniger) angezeigt ("DX" ändert praktisch nichts).

Kann ich das so interpretieren, dass bei Initialisierung des Grafikmodes (z.B. durch SCREENRES) alle Treiber geladen werden, und mit "...GDI" nur der Windows-GDI-Treiber?

Dann wäre das doch eine sinnvolle Code-Optimierung?

Grüße
Rainer