deleted

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	suberror Betreff: deleted	Di, Aug 15, 2006 19:56 Antworten mit Zitat
gelöscht

suberror

Betreff: deleted

Di, Aug 15, 2006 19:56
Antworten mit Zitat

gelöscht

Zuletzt bearbeitet von suberror am Sa, Mai 06, 2017 16:10, insgesamt einmal bearbeitet

	sven123	Di, Aug 15, 2006 21:49 Antworten mit Zitat
Sorry verguckt. Keine Ahnung ich kann aber mal Raten. Vieleicht liegt der Fehler in den Functionen die du da hast. Oder du muss das Field freigeben am Ende. Die Variabele Test ist ja als Local defniert und wird automatisch freigegeben.
Amd Athlon 2200+,Saphire Atlantis Radeon9800pro,1024 MB DDR RAm,40 Gb Festblatte. 'in shâ'a llâh=so Gott will Fertiges Projekt:Invasion der Heuschrecken

sven123

Di, Aug 15, 2006 21:49
Antworten mit Zitat

Sorry verguckt. Keine Ahnung ich kann aber mal Raten. Vieleicht liegt der Fehler in den Functionen die du da hast. Oder du muss das Field freigeben am Ende. Die Variabele Test ist ja als Local defniert und wird automatisch freigegeben.

Amd Athlon 2200+,Saphire Atlantis Radeon9800pro,1024 MB DDR RAm,40 Gb Festblatte.
'in shâ'a llâh=so Gott will
Fertiges Projekt:Invasion der Heuschrecken

	klepto2	Di, Aug 15, 2006 22:53 Antworten mit Zitat
Also dein Code liefert keinen Memleak, (jedenfalls das Beispiel). das nicht alles freigegeben wird daran liegen, das Bmax intern ebenfalls Resourcen verbraucht und diese als letztes wieder freigibt. Schau mal in deinen Hauptcode, ob du irgendwelche Referenzen an den Type übergibst, z.B eine Liste oder einen array, der noch irgendwo anders verwendet wird. Denn dann wird deine Type Instanz nicht vom GC gelöscht. Ebenfalls solltest du mal darauf achten, ob der Speicher nach einer Gewissen zeit wieder freigegeben wird, der GC wird nämlich nicht jedesmal ausgeführt, sondern nur wenn es sich auch lohnt.
Matrix Screensaver Console Modul für BlitzMax KLPacker Modul für BlitzMax HomePage : http://www.brsoftware.de.vu

klepto2

Di, Aug 15, 2006 22:53
Antworten mit Zitat

Also dein Code liefert keinen Memleak, (jedenfalls das Beispiel). das nicht alles
freigegeben wird daran liegen, das Bmax intern ebenfalls Resourcen verbraucht und diese als letztes wieder freigibt.

Schau mal in deinen Hauptcode, ob du irgendwelche Referenzen an den Type übergibst, z.B eine Liste oder einen array, der noch irgendwo anders verwendet wird. Denn dann wird deine Type Instanz nicht vom GC gelöscht.

Ebenfalls solltest du mal darauf achten, ob der Speicher nach einer Gewissen zeit wieder freigegeben wird, der GC wird nämlich nicht jedesmal ausgeführt, sondern nur wenn es sich auch lohnt.

Matrix Screensaver
Console Modul für BlitzMax
KLPacker Modul für BlitzMax

HomePage : http://www.brsoftware.de.vu

	Dreamora	Di, Aug 15, 2006 23:09 Antworten mit Zitat
Hast du die aktuellste Version drauf?
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Di, Aug 15, 2006 23:09
Antworten mit Zitat

Hast du die aktuellste Version drauf?

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	suberror	Mi, Aug 16, 2006 7:09 Antworten mit Zitat
gelöscht

suberror

Mi, Aug 16, 2006 7:09
Antworten mit Zitat

gelöscht

Zuletzt bearbeitet von suberror am Sa, Mai 06, 2017 16:11, insgesamt einmal bearbeitet

	Dreamora	Mi, Aug 16, 2006 7:31 Antworten mit Zitat
Poste bitte keine angeblichen Leaks solange du kein Strict verwendest, da scoping nur funktioniert wenn Strict / SuperStrict aktiv is. Damit wäre dein angebliches Problem im 2ten Code geklärt. Dann was Leaks angeht: Leaks kann man NUR mit schleifen zeigen wo der speicherverbrauch mindestens in konstanten Schritten rauf geht. Sprich das erste Beispiel ist schonmal komplett wertlos und auch ganz normal, dass der Grundspeicherverbrauch nach Graphics höher ist, weil halt Grafikcontextdaten gehalten werden damit sie beim Re-Graphic-en nicht nochmal alle erfragt werden müssen. Hinzu kommt: Solange du auf jedes Byte schaust, geh doch bitte C nutzen. Ein normaler GC würde überhaupt keinen Speicher freigeben, solange noch freier Platz im RAM ist, weils ganz einfach ineffizient ist ... BM hat auch pooling, gibt also den speicher erst nach einiger zeit frei, da kannst du collect aufrufen bis du schwarz bist. Performance ist definitiv wichtiger als 20kb mehr oder weniger. Aber ich denke du musst dich erst mal an die Funktionsweise von Programmiersprachen mit GC gewöhnen, denn sie arbeiten grundlegend anders als zb die alten Blitz Sprachen oder C / C++!
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 16, 2006 7:31
Antworten mit Zitat

Poste bitte keine angeblichen Leaks solange du kein Strict verwendest, da scoping nur funktioniert wenn Strict / SuperStrict aktiv is. Damit wäre dein angebliches Problem im 2ten Code geklärt.

Dann was Leaks angeht: Leaks kann man NUR mit schleifen zeigen wo der speicherverbrauch mindestens in konstanten Schritten rauf geht.
Sprich das erste Beispiel ist schonmal komplett wertlos und auch ganz normal, dass der Grundspeicherverbrauch nach Graphics höher ist, weil halt Grafikcontextdaten gehalten werden damit sie beim Re-Graphic-en nicht nochmal alle erfragt werden müssen.

Hinzu kommt: Solange du auf jedes Byte schaust, geh doch bitte C nutzen. Ein normaler GC würde überhaupt keinen Speicher freigeben, solange noch freier Platz im RAM ist, weils ganz einfach ineffizient ist ... BM hat auch pooling, gibt also den speicher erst nach einiger zeit frei, da kannst du collect aufrufen bis du schwarz bist. Performance ist definitiv wichtiger als 20kb mehr oder weniger.
Aber ich denke du musst dich erst mal an die Funktionsweise von Programmiersprachen mit GC gewöhnen, denn sie arbeiten grundlegend anders als zb die alten Blitz Sprachen oder C / C++!

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	suberror	Mi, Aug 16, 2006 7:57 Antworten mit Zitat
gelöscht

suberror

Mi, Aug 16, 2006 7:57
Antworten mit Zitat

gelöscht

Zuletzt bearbeitet von suberror am Sa, Mai 06, 2017 16:11, insgesamt einmal bearbeitet

	Dreamora	Mi, Aug 16, 2006 8:53 Antworten mit Zitat
Ein leak kann nur gezeigt werden wenn der speicherverbraucht konstant weiter steigt, wenn man die operation in einer Loop aufruft. Solange du es nicht in einer Loop machst, hat rein garnichts potential ein leak zu sein, sorry, da es dann ganz einfach auch nur Poolingverhalten sein kann und meist auch ist. (nur weil grad nix den speicher nutzt gibt der GC ihn nicht direkt wieder frei, da Speicher vom OS anfordern und zurückgeben zeitintensiv ist und je grösser der Speicher ist der angefordert wurde, desto länger wird er potentiell auch bleiben) Scoping: Local und global funktionieren ziemlich anders, wenn du strict / superstrict nutzt verglichen dazu wenn du es nicht tust. Strict ist von daher das erste was in einem code zu stehen hat, Probleme die auftreten wenn man strict nicht aktiviert hat liegen ziemlich häufig daran dass kein Scoping aktiv ist. Ein Scope ist eine Schleife zum beispiel oder ein if. Wenn du innerhalb eines ifs ein local machst und kein Strict drin hast, ist diese local überall existent innerhalb dieser funktion. Mit Strict würde das local am ende der schleife / if jedoch wieder zerstört. Bei deinem zweiten beispiel, das du angeblich als "funzt nicht" deklariert hast ist es so dass alle speicherverbrauche gleich sind (ok der erste ist 2byte höher als die anderen) Code: [AUSKLAPPEN] [EINKLAPPEN] Strict GCCollect() Print "MEM: " + GCMemAlloced() For Local i:Int = 1 To 100 Graphics(640,480) Cls Flip EndGraphics() Print "Freed on run " + i + ": " + GCCollect() Print "MEM: " + GCMemAlloced() Next So würde man ein Leak zeigen. Wie du aber siehst, wirds bei 80,3kb aufhören zu steigen und einpendeln. So verhalten sich managed Systeme nunma. Da kann und darf man nimmer so programmieren wie mit Blitz3D, da man dann den GC zur Weissglut bringt. Sprich wer der meinung ist dass ständiges New und Delete eine intelligente Programmierart ist, sollte besser bei Blitz Plus und Blitz3D bleiben.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 16, 2006 8:53
Antworten mit Zitat

Ein leak kann nur gezeigt werden wenn der speicherverbraucht konstant weiter steigt, wenn man die operation in einer Loop aufruft.
Solange du es nicht in einer Loop machst, hat rein garnichts potential ein leak zu sein, sorry, da es dann ganz einfach auch nur Poolingverhalten sein kann und meist auch ist. (nur weil grad nix den speicher nutzt gibt der GC ihn nicht direkt wieder frei, da Speicher vom OS anfordern und zurückgeben zeitintensiv ist und je grösser der Speicher ist der angefordert wurde, desto länger wird er potentiell auch bleiben)

Scoping: Local und global funktionieren ziemlich anders, wenn du strict / superstrict nutzt verglichen dazu wenn du es nicht tust. Strict ist von daher das erste was in einem code zu stehen hat, Probleme die auftreten wenn man strict nicht aktiviert hat liegen ziemlich häufig daran dass kein Scoping aktiv ist. Ein Scope ist eine Schleife zum beispiel oder ein if. Wenn du innerhalb eines ifs ein local machst und kein Strict drin hast, ist diese local überall existent innerhalb dieser funktion. Mit Strict würde das local am ende der schleife / if jedoch wieder zerstört.

Bei deinem zweiten beispiel, das du angeblich als "funzt nicht" deklariert hast ist es so dass alle speicherverbrauche gleich sind (ok der erste ist 2byte höher als die anderen)

Code: [AUSKLAPPEN]

Strict
GCCollect()
Print "MEM: " + GCMemAlloced()

For Local i:Int = 1 To 100
Graphics(640,480)
Cls
Flip
EndGraphics()

Print "Freed on run " + i + ": " + GCCollect()
Print "MEM: " + GCMemAlloced()
Next

So würde man ein Leak zeigen. Wie du aber siehst, wirds bei 80,3kb aufhören zu steigen und einpendeln.

So verhalten sich managed Systeme nunma. Da kann und darf man nimmer so programmieren wie mit Blitz3D, da man dann den GC zur Weissglut bringt. Sprich wer der meinung ist dass ständiges New und Delete eine intelligente Programmierart ist, sollte besser bei Blitz Plus und Blitz3D bleiben.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

deleted

Betreff: deleted