TYPE - Array nimmt sich ziemlich viel (Speicher) raus

[Schnatterplatsch]

Hallo,

GLBasic ist wirklich was für Kriminologen (...oder wie heißen die Typen, die Larven aufschlitzen um rauszubekommen wann Person X ermordet wurde?) Ich nehm an, dass ich wieder der einzige Mensch auf Terra bin, der dieses, wirklich erstaunlich spannende, Problem sein eigen nennt(kann man Probleme besitzen? ...oder besitzen einen die Probleme?). Es geht um folgendes: ein völlig harmlos aussehendes GLB-Programm nimmt sich laut Taskmanager Unmengen von RAM. Bei mir waren es z.T. 270 MB!!! Mal angenommen, der Taskmanager zeigt korrekte Werte an, dann stimmt hier einfach irgendwas nicht. Achja, worum gehtââ,¬â,,¢s in dem Programm eigentlich? Ich hänge ââ,¬Å¾HugeTypeWTF.gbasââ,¬Å" mal an. Könnt das ja mal testen, ob das bei euch genau so ist (keine Sorge, bei mir lies sich immer alles sauber beenden, ohne das mein Rechner abstürzte).

Kurze Erleuterung zum Problem(HugeTypeWTF_1.gbas):

Ich habe TCampaign[1]  vom TYPE Type_Campaign, der 20 TYPES Type_Level und die Anzahl der Level enthält. Die restlichen ââ,¬Å¾Verbindungenââ,¬Å" sollten recht gut aus dem Code lesbar sein. Mein Problem beginnt beim Level[20]. Ändere ich 20 in 1 um und starte das Programm, zeigt der Taskmanager mir einen verbrauchten RAM von 100MB an. Bei 3 ebenfalls, bei 10 sind es 190, bei 15 ebenfalls, bei 18 sind es bereits 280. Das sollte eigentlich schon zeigen, dass hier etwas ÃÅ"BERHAUPTNICHT stimmt. Ich rechne mal vor: bei 1 Leveln nimmt er sich pro Level 100MB, bei 3 sind es 33MB/Level , bei 10 sind es 19MB/Level, bei 18 sind es 15,5/MB/Level. Es lässt sich erahnen, warum da oben ââ,¬Å¾WTFââ,¬Å" steht. Kommt aber noch besser. Schreibe ich nämlich statt Level[1] AS Type_Level , Level AS Type_Level nimmt er sich vollkommen normale 12MB, obwohl der Speicherbedarf doch der gleiche sein sollte?!? Selbiges passiert übrigens auch, wenn ich statt
TCampaign[] AS Type_Campaign;DIM TCampaign[1]
→
TCampaign AS Type_Campaign
schreibe. Der Speicherbedarf liegt bei 12 MB,  auch wenn man 20 Level reinhaut. Seit wann unterscheidet sich ein eindimensionales Int-Array mit einem Feld von einem ganz normalen Int (vom Speicherbedarf betrachtet)?

280 bzw 272 MB scheint das Maximum zu sein, was an Speicher angefordert werden kann. Dieser Wert wird auch bei 10 Campaigns mit 20 Leveln nicht überschritten.

Liegt hier ein Problem mit meinem Taskmanager vor, oder wird im C++ Code (evtl. mt malloc()?) bei TYPE-Arrays zuviel Speicher angefordert.

Leute, manchmal HASSE ich GLB...

gruß und SOS

PS: Habe GLB 7.206, WinXP SP2, AMD Athlon 3800+(single), 1024 MB RAM, 160 GB HD und eine Logitechmaus.

PPS: Ich poste das erstmal nicht beim Fehlermelder. Die meisten meiner "Fehler" scheinen entweder keine zu sein, oder immer nur bei mir aufzutreten. Sollte einen Mod dass stören, verschiebt einfach.

[attachment deleted by admin]

[Schranz0r]

Glaube nicht, das du die Arraygröße in Relation zum Speicherverbrauch nehmen solltest, da im Hintergrund von GLB da mehr abläuft. Ist aber nur meine Meinung, genaueres kann dir da wohl nur Gernot sagen.

[Kitty Hello]

Wenn die Types recht groß sind, kann es vorkommen, dass DIMPUSH mehr speicher alloziiert als nötig (und damit beim nächsten DIMPUSH schneller ist). Ich frage intern aber die Größe der Types ab und behandle das getrennt. Ist 200 MB wirklich ein Problem?

Gruß,
-Gernot

[Schnatterplatsch]

Wenn die Types recht groß sind, kann es vorkommen, dass DIMPUSH mehr speicher alloziiert als nötig (und damit beim nächsten DIMPUSH schneller ist). Ich frage intern aber die Größe der Types ab und behandle das getrennt. Ist 200 MB wirklich ein Problem?

Gruß,
-Gernot

Ob 200 MB (inzwischen auch mal 300) ein Problem sind kann ich so genau nicht sagen. Er scheint sich ja so viel Speicher zu krallen wie er am Stück bekommen kann unnd stürzt anscheinend nicht ab, wenn dieser nicht verfügbar ist. Das Programm beendet sich etwas träge. Schlimm wirds erst, wenn das auf dem WiZ/Pandora genauso ist. Dann bleibt nämlich nach dem laden der Campagne kein Platz mehr für die Grafiken.

DIMPUSH verwende ich nur höchst selten, und auch nur an Stellen an denen die Perfo egal ist.


gruß

[Kitty Hello]

Auf dem Wiz ist er viel sparsamer, das sollte passen.

[Schnatterplatsch]

Ich muss in dieser Sache nochmal nachhaken. Ich habe nun mit C - INLINE und sizeof() die Größe meines TYPES TYPE_Ship abgefragt, das waren 1064 Bytes. Wird nun ein Array mit 30 Elementen vom TYPE_Ship initialisiert verbraucht das Programm 108MB mehr, also rund das 3200 fache(!) von dem was eigentlich notwendig wäre. Oder hab ich mich da verrechnet? Das haöte ich schon für ein bisschen übertrieben viel. Stören tut mich nur folgendes:

Beim TYPE_Shot mit rund 800 Bytes muss ich oft die Arraygröße von RShot[] ändern, die Shots die gerade existieren, da ja ständig neue erzeugt und alte gelöscht werden. Ein REDiM ist hier während der Laufzeit des Programmes im Moment extrem unperformant, z.t. pro schuss 1-2 ms Aussetzter, wie kann das sein? Selbst die Zuweisung eines LOCALen shot AS TYPE_Shot per shot = RShot

• dauert 0.1-0.3 ms, wodurch man quasi REDIM nehmen muss, da ein einfaches verschieben der existenten Schüsse im Array zu langsam ist. Aber auch REDIM ist ja viel zu langsam. Houston ich habe ein Problem...
  
  Beispielcode mach ich noch, sind aber bloß nested Array-TYPES mit 5-10 Members(z.T. ebenfalls Array/Arraytypes) jeweils und wie gesagt knapp 1KB größe

[Kitty Hello]

Bei extrem kleinen Types mache ich im Hintergrund bei Felder größere Voralloziiereungen, weil dann REDIM/DIMPUSH viel schneller geht. Mach ein Beispiel, Da ist bestimmt ein anderer Denkfehler drin.

[Schnatterplatsch]

Hier, bittesehr


sizeof() bringt bei Arrays leider keinen korrekten Wert zutage. Ich rechne nachher mal die eigentliche Größe von TTest aus.

EDIT: in der Eile das REDIM ganz vergessen. Ist jetzt mit drin.

[attachment deleted by admin]

[Kitty Hello]

OK, hab's verstanden. Der meint das TYPE ist klein und alliziiert viele davon. Dabei hat das fest vorgegebene Speichergrößen. Ich muss das ändern.

[Kitty Hello]

OK. Hintergrund:
GLBasic alloziiert für int und float Felder immer 10 elemente statisch. Das macht es bei kleinen Arrays viel schneller. Du alloziierst 15, also hast Du 10 + 15 pro Feld. Das mutipliziert sich hoch.

Wenn ich das wegmache (Wie Du das willst), dauert Dein Programm bei mir exakt 3x so lange (1200ms statt 400).

Ich brauche jetzt bisserl weniger Speicher, nämlich 280 MB.

Deine Speicherverwaltung ist aber extrem uneffektiv. Warum brauchst Du für jedes TTest_a so einen großen Vorbelegungsspeicher? Reicht das nicht, wenn man das kleiner macht?

[Schnatterplatsch]

Hi,

ich habs mal duchgerechnet. Sorry, es ist wirklich viel zu viel speicher, den ich anfordere. Ich dachte, das läge an GLB. Danke für die Hilfe.

Mein Hintergrund: Das was ich da mit Test_a usw. dargestellt habe ist in meinem Spiel der TYPE_Shot. Der hat bis vor kurzem wunderbar schnell funktioniert, was das REDIM angeht. Jetzt hatte ich ein wenig was an der Struktur geändert und plötzlich stockte das ganze Spiel wenn ich schoss. Da meine Änderungen nicht besonders gravierend waren, dachte ich GLB macht da im Hintergrund was falsch.

Könntest du das so einrichten, dass wenn im ganzen Quelltext kein REDIM des Arrays auftaucht, dass dann kein zusätzlicher Speicher alloziert wird? Oder ist das bereits so? Ich hab nochmals ein Programm angehängt, welches die Realität nun recht real wiederspiegelt , und nicht wie vorher einfach so dahingeschrieben wurde. Ich habe recht sorgfältig den benötigten Speicher durchgerechnet, aber es wird dennoch viel zu viel Speicher alloziert. Hab auch ein paar Comments gemacht, hoffe, man kann das nachvollziehen.

gruß

[attachment deleted by admin]

[Kitty Hello]

Dein POINT hat 2 floats. Die sind unter win32 8 byte lang, jeweils (4 byte auf Wiz und iPhone).

[Schnatterplatsch]

... und 2x8 Bytes sind 16 Bytes, oder? Was anderes steht doch da nicht