Objektarray - Speicherverschwendung?

Hag2bard

Bekanntes Mitglied
Hallo,

ich habe folgendes vor:

Ich habe ein Spielfeld mit 20x60 Feldern.
Um jedes Feld zu beschreiben benötige ich 4 int Zahlen. (ZielX, ZielY, SourceX, SourceY)
Da manche Felder doppelt belegt werden (2 Layer), glaube ich, ist eine ArrayList die bessere Wahl.
Das heißt 20x60 Felder ergeben 1200 Felder mit 4 Ints, manchmal sogar mit 8 ints.
Ich dachte daran ein Objekt für jedes Feld zu erstellen, welches die 4(8) Int Zahlen beherbergt. Das heißt ich hätte eine ArrayList mit 1200 Objekten.

Ist das Speicherverschwendung? Ein Objekt würde mir natürlich super Möglichkeiten bieten. Ich könnte Methoden implementieren, die mir ZielX usw ausgeben und auch einen Boolean ob es sich um ein 2 Layer Feld handelt.

Mein bisheriger Aufbau des Spielfeldes war mit einem 3D Array
Al[1][0][72] = 23;// Zielkoordinate X
Al[1][1][72] = 2;// Zielkoordinate Y
Al[2][0][72] = 5;// Quellkoordinate X
Al[2][1][72] = 1;// Quellkoordinate Y

Al[1][0][73] = 23;// Zielkoordinate X
Al[1][1][73] = 2;// Zielkoordinate Y (2. Layer)
Al[2][0][73] = 7;// Quellkoordinate X
Al[2][1][73] = 4;// Quellkoordinate Y

Wie gehe ich das Problem möglichst resourcenschonend an?
 

httpdigest

Top Contributor
Nutze hier ruhig Klassen/Objekte und strukturiere deine Informationen entsprechend. 1200 Objekte mit 2 ints (und evtl. noch einem boolean) ist absolut rein gar nichts im Gegensatz zu den 10-50MB., die die JVM sowieso zum Starten benötigt.
Und bei solch geringen Größenordnungen geht Lesbarkeit/Wartbarkeit des Codes IMMER vor!

Wenn du auf Performance-/Ressourcenschonung optimieren möchtest, brauchst du erstmal ein Problem und eine zu messende Zielgröße bzw. ein Budget/Limit, das du erreichen möchtest. In diesem Fall lohnt sich so etwas aber nicht, weil 1. die Messbarkeit nicht gegeben ist (deine paar Objekte gehen absolut unter gemessen neben dem Speicher, den die JVM sowieso für sich braucht) und 2. auch kein Problem (zu viel Speicherverbrauch) vorliegt.

Optimiere immer nur dann, wenn du auch ein Problem hast und optimiere erst, wenn du einen Erfolg auch messen kannst.
Plus: Codelesbarkeit und -wartbarkeit ist auch ein gewichtiger und (qualitativ) messbarer Optimierungsfaktor!
 
K

kneitzel

Gast
Nur um das mal etwas mit Größen zu versehen:

Größe eines Objekts: 4 Variablen a 4 Bytes + etwas Overhead -> 16 Bytes + etwas Overhead.
1200 dieser Objekte -> Selbst wenn der Overhead groß wäre (was er nicht ist!) und wir dann von einer Objektgröße um 870 Bytes ausgehen, dann wäre das gerade mal 1 MB Speicher.

Da ist jede Diskussion sinnlos, denn wie viel wird durch JVM und Java Klassen direkt verbraucht? Einfach mal anschauen, wie viel Speicher die JVM direkt beim Start reserviert. 1 MB sind da lachhaft.

Und dann der theoretische Aspekt - Was ist wie wichtig?
Clean Code ist wichtig. Denn der Code muss a) funktionieren und b) muss er erweitert werden können (das einfach als grundlegende Regel. Klar, ein Hello World will man nicht wirklich erweitern).
Und dann gibt es klare Regeln - z.B. zu Optimierungen. Und da gibt es dann klare Aussagen zu. Ich mag die Aussage von clean-code-developers.de, die schlicht besagt: Lass es! Keine Optimierungen! Wird dann noch ergänzt: Für Experten: Mach diese noch nicht jetzt!

Der Ansatz ist also 100% richtig und du solltest da entsprechende Klassen schaffen, die die Daten vernünftig kapseln.
 

temi

Top Contributor
Falls nicht alle der 20x60 Felder immer auch alle Informationen enthalten, könnte man den einzelnen Objekten auch die Koordinaten des Feldes mitgeben und dann nur für die tatsächlich benötigen (also die Felder, die auch Daten enthalten) ein Objekt anlegen. Aber es gilt natürlich, was in den Beiträgen vorher schon geschrieben worden ist.
 

Hag2bard

Bekanntes Mitglied
@mihe7
Ich möchte auf eine JComponent zeichnen, dafür habe ich ein BufferedImage als Quellbild, (ein Tileset) und daraus bastel ich mir ein Spielfeld zusammen.
Da ich Probleme mit meiner Gui habe und im Java AWT, Swing, FX Forum momentan keiner da ist um zu antworten, arbeite ich an anderer Stelle weiter.
 

Ähnliche Java Themen

Neue Themen


Oben