Performance: Objekt in Variable vs Objekt ohne Verweis

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

	Toby Betreff: Performance: Objekt in Variable vs Objekt ohne Verweis	Do, Aug 07, 2014 11:18 Antworten mit Zitat
Hallo, ich melde mich nach sehr langer Inaktivität mit einer Frage zurück (angemeldet seit 2003 ) Ich bin seit ein paar Wochen dank BlitzMax wieder blitzig unterwegs, und stoße dabei auf folgendes Problem: ich kam leider noch nicht zu einem 100%igen Ergebnis und ein reiner Test mit Systemprofiler schien mir zu unprofessionell Hat es bzgl. Speicherverbrauchs Vorteile ein Objekt nicht in einer Variable, Array zu speichern sondern unreferenziert zu belassen? Also vergrößert sich der Speicherplatz durch den neuen Referenzwert? Allein von der/meiner Logik her müsste ein Objekt, das in einer Variable referenziert wird doch eben erst diese Referenz erstellt werden und somit entsprechend mehr Speicher fressen. Aber ich bitte um kompetente Berichtigung! Konkret geht es bei mir um Vertex bei minib3d. (Referenz = Int?) Und die Frage ob ich sie unreferenziert dahindümpel lasse und mein Mesh jedesmal lieber neu aufbaue oder ob sich der ggf. enstehende Speicherverbrauch rentiert. (aber bitte in erster Linie Antworten zum Speicherverbrauch) Weitere Frage: Gibt es vielleicht eine Grundlegenden Dokumentation zum Speicherverbrauch, effizienz de BM-Typen TMap, TList die über das Standard MaxIDE-Befehlverzeichnis hinausführt? Ich danke Euch jetzt schon für Eure Hilfe! Dankbare Grüße!
Member of Terra Multimedia

Toby

Betreff: Performance: Objekt in Variable vs Objekt ohne Verweis

Do, Aug 07, 2014 11:18
Antworten mit Zitat

Hallo, ich melde mich nach sehr langer Inaktivität mit einer Frage zurück (angemeldet seit 2003 Shocked

)
Ich bin seit ein paar Wochen dank BlitzMax wieder blitzig unterwegs,
und stoße dabei auf folgendes Problem:

ich kam leider noch nicht zu einem 100%igen Ergebnis und ein reiner Test mit Systemprofiler schien mir zu unprofessionell Very Happy

Hat es bzgl. Speicherverbrauchs Vorteile ein Objekt nicht in einer Variable, Array zu speichern sondern unreferenziert zu belassen?
Also vergrößert sich der Speicherplatz durch den neuen Referenzwert?

Allein von der/meiner Logik her müsste ein Objekt, das in einer Variable referenziert wird doch eben erst diese Referenz erstellt werden und somit entsprechend mehr Speicher fressen.
Aber ich bitte um kompetente Berichtigung!

Konkret geht es bei mir um Vertex bei minib3d. (Referenz = Int?)
Und die Frage ob ich sie unreferenziert dahindümpel lasse und mein Mesh jedesmal lieber neu aufbaue oder ob sich der ggf. enstehende Speicherverbrauch rentiert. (aber bitte in erster Linie Antworten zum Speicherverbrauch)

Weitere Frage:
Gibt es vielleicht eine Grundlegenden Dokumentation zum Speicherverbrauch, effizienz de BM-Typen TMap, TList die über das Standard MaxIDE-Befehlverzeichnis hinausführt?

Ich danke Euch jetzt schon für Eure Hilfe!
Dankbare Grüße! Wink

Member of
Terra Multimedia

	Xeres Moderator	Do, Aug 07, 2014 14:01 Antworten mit Zitat
In BlitzMax gibt es nur Referenzen auf Objekte. Wenn es keine Referenz mehr auf ein Objekt gibt, wird es vom Garbage Collector eingesammelt. Der reservierte Speicher wird sich nicht schnell ändern. Wenn viel Speicher benutzt wurde, geht der GC davon aus, dass dieser gleich wieder befüllt wird. Eine neue Referenz auf das gleiche Objekte sollte minimalen Speicherplatz verbrauchen. Wenn du nicht im Strict-modus arbeitest und mit Integer handels hantierst - keine Ahnung was da für Magie passiert. Sollte man vermeiden.
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Do, Aug 07, 2014 14:01
Antworten mit Zitat

In BlitzMax gibt es nur Referenzen auf Objekte. Wenn es keine Referenz mehr auf ein Objekt gibt, wird es vom Garbage Collector eingesammelt. Der reservierte Speicher wird sich nicht schnell ändern. Wenn viel Speicher benutzt wurde, geht der GC davon aus, dass dieser gleich wieder befüllt wird.
Eine neue Referenz auf das gleiche Objekte sollte minimalen Speicherplatz verbrauchen.

Wenn du nicht im Strict-modus arbeitest und mit Integer handels hantierst - keine Ahnung was da für Magie passiert. Sollte man vermeiden.

Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus
THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

	DAK	Do, Aug 07, 2014 14:48 Antworten mit Zitat
Eine Referenz ist ein Pointer ist in x86 4 Byte. Das heißt, pro Referenz zahlst du 4 Byte, gleich viel also wie für ein Int, ein Float oder einen vier Zeichen langen String. Referenzen kannst du nur umgehen, indem du Primitive verwendest, die am Stack stehen und nicht am Heap. Das ist dann der Fall, wenn du Ints, Floats oder Doubles verwendest, die entweder in normalen Variablen stehen. Ein Array oder ein großes Objekt ist auch noch ziemlich ressourcensparend, da es nur eine Referenz pro Array/Objekt gibt, egal wie viele Primitive in diesem Array/Objekt gespeichert werden. Objekte in Arrays oder anderen Objekten brauchen natürlich wieder eine Referenz pro Objekt. Solche Optimierungen sind aber aufgrund der winzigen Größe nur dann sinnvoll, wenn man sehr viele kleine Objekte hat (mehrere zehntausend Objekte mit je weniger als drei oder vier Byte Nutzdaten pro Objekt). In so einem Fall sollte man sich aber generell überlegen, ob man hier wirklich Objekte braucht, oder einem nicht mit einem mehrdimensionalen Array o.Ä. besser gedient wäre. Hauptsächlich aber deswegen, weil das Erstellen und Löschen (mittels Garbage Collector) bei solchen Mengen an Objekten sehr teuer sein kann.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Do, Aug 07, 2014 14:48
Antworten mit Zitat

Eine Referenz ist ein Pointer ist in x86 4 Byte.
Das heißt, pro Referenz zahlst du 4 Byte, gleich viel also wie für ein Int, ein Float oder einen vier Zeichen langen String.

Referenzen kannst du nur umgehen, indem du Primitive verwendest, die am Stack stehen und nicht am Heap. Das ist dann der Fall, wenn du Ints, Floats oder Doubles verwendest, die entweder in normalen Variablen stehen. Ein Array oder ein großes Objekt ist auch noch ziemlich ressourcensparend, da es nur eine Referenz pro Array/Objekt gibt, egal wie viele Primitive in diesem Array/Objekt gespeichert werden.
Objekte in Arrays oder anderen Objekten brauchen natürlich wieder eine Referenz pro Objekt.

Solche Optimierungen sind aber aufgrund der winzigen Größe nur dann sinnvoll, wenn man sehr viele kleine Objekte hat (mehrere zehntausend Objekte mit je weniger als drei oder vier Byte Nutzdaten pro Objekt). In so einem Fall sollte man sich aber generell überlegen, ob man hier wirklich Objekte braucht, oder einem nicht mit einem mehrdimensionalen Array o.Ä. besser gedient wäre. Hauptsächlich aber deswegen, weil das Erstellen und Löschen (mittels Garbage Collector) bei solchen Mengen an Objekten sehr teuer sein kann.

Gewinner der 6. und der 68. BlitzCodeCompo

	Thunder	Do, Aug 07, 2014 17:50 Antworten mit Zitat
Also bezüglich TList steht in der Doku eigentlich alles, was du wissen musst. Ein TList-Objekt enthält eine Referenz auf ein TLink-Objekt. Jedes TLink-Objekt enthält zwei Referenzen auf TLinks (vorheriges/nächstes Element der Liste) und eine Referenz auf das eigentliche Objekt, das in der Liste an der Position gespeichert wird. Das ist der normale Aufbau einer Doubly Linked List und TList hat daher ihre Eigenschaften, was Geschwindigkeit und Komplexität angeht. Speicherplatz ist in BlitzMax so eine Sache... du kannst dir nie sicher sein. Deine Bedenken wegen Referenzen sind etwas komisch, denn eine Referenz ist in BlitzMax 4 Byte groß und wenn du ein Type hast, das z.B. so aussieht: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] Type Foo Field a,b ' 2x Int -> 8 Byte Field c:Byte Ptr ' 1 x Ptr -> 4 Byte End Type ' gesamt -> 12 Byte für ein Objekt ... richtig? Falsch. BlitzMax speichert fix zu jedem Objekt zusätzlich 8 Byte Metadaten, soweit ich das im Kopf hab. Wenn du volle Kontrolle brauchst und es wirklich drauf ankommt: MemAlloc, MemExtend und MemFree sind deine Freunde, oder gewisse Teile in C schreiben, oder komplett weg von BlitzMax.

Thunder

Do, Aug 07, 2014 17:50
Antworten mit Zitat

Also bezüglich TList steht in der Doku eigentlich alles, was du wissen musst. Ein TList-Objekt enthält eine Referenz auf ein TLink-Objekt. Jedes TLink-Objekt enthält zwei Referenzen auf TLinks (vorheriges/nächstes Element der Liste) und eine Referenz auf das eigentliche Objekt, das in der Liste an der Position gespeichert wird.
Das ist der normale Aufbau einer Doubly Linked List und TList hat daher ihre Eigenschaften, was Geschwindigkeit und Komplexität angeht.

Speicherplatz ist in BlitzMax so eine Sache... du kannst dir nie sicher sein. Deine Bedenken wegen Referenzen sind etwas komisch, denn eine Referenz ist in BlitzMax 4 Byte groß und wenn du ein Type hast, das z.B. so aussieht:
BlitzMax: [AUSKLAPPEN]

Type Foo
    Field a,b ' 2x Int -> 8 Byte
    Field c:Byte Ptr ' 1 x Ptr -> 4 Byte
End Type ' gesamt -> 12 Byte für ein Objekt ... richtig?

Falsch. BlitzMax speichert fix zu jedem Objekt zusätzlich 8 Byte Metadaten, soweit ich das im Kopf hab.

Wenn du volle Kontrolle brauchst und es wirklich drauf ankommt: MemAlloc, MemExtend und MemFree sind deine Freunde, oder gewisse Teile in C schreiben, oder komplett weg von BlitzMax.

	DAK	Do, Aug 07, 2014 21:00 Antworten mit Zitat
Hab die Frage mit der Liste ganz übersehen. Listen verwenden im Gegensatz zu Arrays (wie Thunder schon geschrieben hat) für jedes Objekt ein TLink-Objekt. Brauchst du die Flexibilität von Listen aber eine sinnvolle Performance schau dir Arraylists an, die sind sehr einfach zu implementieren (vor allem in BMax, wo es Slices gibt) und beinahe so effizient wie Arrays. Hashmaps lassen sich auch vergleichsweise einfach auf ein Array zurück führen und brauchen so weniger Speicherplatz. Brauchst du was Spezielleres schau dir die Wikipedia-Artikel zu Datenstrukturen durch. Wenn du so große Datenmengen hast, dass der Speicherverbrauch so arg ins Gewicht fällt, ist aber meist die Geschwindigkeit zuerst danieder, wenn du nicht die passenden Datenstrukturen verwendest. Wofür brauchst du das denn? Vielleicht können wir dir dann etwas besser helfen.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Do, Aug 07, 2014 21:00
Antworten mit Zitat

Hab die Frage mit der Liste ganz übersehen. Listen verwenden im Gegensatz zu Arrays (wie Thunder schon geschrieben hat) für jedes Objekt ein TLink-Objekt.

Brauchst du die Flexibilität von Listen aber eine sinnvolle Performance schau dir Arraylists an, die sind sehr einfach zu implementieren (vor allem in BMax, wo es Slices gibt) und beinahe so effizient wie Arrays.

Hashmaps lassen sich auch vergleichsweise einfach auf ein Array zurück führen und brauchen so weniger Speicherplatz.

Brauchst du was Spezielleres schau dir die Wikipedia-Artikel zu Datenstrukturen durch.

Wenn du so große Datenmengen hast, dass der Speicherverbrauch so arg ins Gewicht fällt, ist aber meist die Geschwindigkeit zuerst danieder, wenn du nicht die passenden Datenstrukturen verwendest.

Wofür brauchst du das denn? Vielleicht können wir dir dann etwas besser helfen.

Gewinner der 6. und der 68. BlitzCodeCompo

	Toby	Mo, Aug 11, 2014 18:11 Antworten mit Zitat
Danke habt mir schon sehr geholfen. Werde erstmal eine Weile brauchen alle euren neuen Infos zu verarbeiten und durchzugehen Falls noch weitere Fragen auftauchen melde ich mich hier nochmal, wenn ich darf Dank Euch vielmals!
Member of Terra Multimedia