ist tiefes Kopieren sinnvoll?

[oetzi]

Hallo zusammen,

ich benutze im Moment tiefe Kopien von Objekten mittels ByteArrayOutputStream -> InputStream.
Als ich da mit Kollegen drüber gesprochen habe, waren sie der Meinung, dass man tiefe Kopien eigentlich nie verwenden sollte und das dann wohl eher ein Designfehler vorliegen würde.

Da wir aber auf keine andere Lösung gekommen sind, möchte ich das Problem hier nochmal schildern. Vielleicht könnt ihr mir ja sagen, ob hier das tiefe kopieren die beste Lösung ist, oder ob man es anders machen sollte.

Hintergrundinfos:
- web basiertes Rollenspiel
- es gibt unique-monster, d. h. Monster A gibt es in verschiedenen Ausführungen, die zufällig, basieren auf Standardwerten, generiert werden
- beim Starten des Servers werden u.a. die Basiswerte (id, name, attribute, etc.) von Monstern ausgelesen und in jeweilige Objekte gepackt. Diese Objekte speichere ich in ArrayList<Monster> monsterList
-> Damit möchte ich die Performance verbessern, da nicht jedesmal auf die DB zugegriffen werden muss, wenn die Basiswerte benötigt werden

Problemsituation:
- Brauche ich jetzt ein unique-Monster, rufe ich die Methode "public Monster getUniqueMonster(Integer)" (s.u.) auf und übergebe die Id von dem Viech, wovon ich eine zufällige Variante generiert haben möchte.
- Die Methode sucht innerhalb der monsterList nach diesem Monster und berechnet die zufälligen finalen Werte
-> hier kommt aktuell das tiefe Kopieren zum Einsatz. Würde ich einfach per monsterList.get(i) das Monster holen und bearbeiten, würde ich beim 2. Aufruf der Methode die Werte des 1. zurückgegebenen Monsters verändern, da ich ja auf dem selben Speicherbereich arbeite.

Die Methode sieht aktuell so aus:

	public Monster getUniqueMonsterById(Integer id){
		Monster tmpMonster = null;
		for (int i = 0; i < allMonster.size(); i++) {
			if (allMonster.get(i).getPk_Monster().equals(id)){
				tmpMonster = (Monster) Monster.clone(allMonster.get(i));
				break;
			}
		}
		if (tmpMonster == null){
			System.out.println("ERROR | Es gibt kein Monster mit der ID: "+ id);
		}
		tmpMonster.calculateStandardLevel();
        tmpMonster.createUniqueAttributes();
        tmpMonster.calculateFinalLevel();
        tmpMonster.refreshAllValues();
	return tmpMonster;
	}

(Monster.clone() ist die selbstgeschriebene Methode zum tiefen kopieren)

Ich hoffe, dass das jetzt halbwegs verständlich war

Für mich stellen sich im Moment 2 Fragen:
1. Spricht irgendwas grundsätzlich gegen das Erstellen von tiefen Kopien mittels der ByteArrayOutputStream-Methode? Performance, Ressourcen,...?
2. Gäbe es überhaupt eine andere Mögichkeit das hier zu lösen?

Schönen Gruß
oetzi

 

[Gast2]

Ich würde da eher ein Factory Pattern einsetzen.

Ob du durch kopieren eines bestehenden Objectes wirklich Performance gewinnst mag ich bezweifeln.

 

[oetzi]

Hallo fassy,

ich kenne mich zwar nicht besonders gut mit Factory Pattern aus, aber geht das was ich da mache nicht sogar in die Richtung?
Schließlich rufe ich eine Methode auf, die mir ein neues Objekt zurück liefert.

Und abgesehen davon: Wie soll ich mit dem Factory Pattern das tiefe kopieren umgehen?

 

[Empire Phoenix]

also ich sehe da jetzt nicht wo das Problem ist, wenn die eigene Versionen der Daten brauchen müssen die die auch haben, da hilft nichts.(was mir bekannt wäre)

 

[oetzi]

naja, eine Alternative die naheliegt wäre jedesmal auf die Datenbank zuzugreifen, alle benötigten Daten zu laden und daraus die neuen Objekte zu erzeugen.
Allerdings war es ja genau diesen Vorgang den ich vermeiden wollte, in der Annahme, dass dies wohl der am meisten Ressourcen fressende Ablauf wäre.

Allerdings war das halt nur eine Annahme. Ich lasse mich ja auch gerne vom Gegenteil überzeugen

 

[Landei]

Erste Frage: Habt ihr schon alles immutable gemacht, was sich immutable machen lässt (und das mehr, als man gemeinhin annimmt)? Was sich nicht ändert, braucht man natürlich nicht zu kopieren...

 

[oetzi]

Hallo Landei,

ich verstehe ehrlich gesagt nicht, was das genau mit meinem Problem zu tun hat.
Ich will doch eine Kopie von meinem Objekt haben.
Aber vielleicht habe ich den Sinn von immutable auch einfach nicht richtig verstanden

Gruß
oetzi

 

[FArt]

Anmerkungen:
- Im Prinzip ist das eine Factory. Das Factorypattern an sich wäre schöner, aber sei es drum. Du kannst auch mit Copy-Konstruktor arbeiten usw.
- Clonen ist ok
- vollständiger deep-clone serialisierbarer Objekte über Marshalling/Unmarshalling ist u.U. uncool, weil tatsächlich von allen Objekten Kopien angefertigt werde. Bei Clones nach diesem Muster werden auch Objekte kopiert, die nicht kopiert werden müssen weil sie immutable sind. Außerdem übernimmt die VM eine Optimierung mit Strings (die auch immutable sind) und die du damit aushebelst.
- Wenn deine Kollegen Behauptungen aufstellen, sollten sie die auch begründen können, also nachhaken.

 

[oetzi]

- Clonen ist ok
- vollständiger deep-clone serialisierbarer Objekte über Marshalling/Unmarshalling ist u.U. uncool, weil tatsächlich von allen Objekten Kopien angefertigt werde. Bei Clones nach diesem Muster werden auch Objekte kopiert, die nicht kopiert werden müssen weil sie immutable sind. Außerdem übernimmt die VM eine Optimierung mit Strings (die auch immutable sind) und die du damit aushebelst.

Naja, das Problem ist einfach, dass diese Klasse "Monster" natürlich Attribute wie name, beschreibung, etc. hat, die für alle Instanzen gleich sind, allerdings auch viele (die Mehrheit) die wirklich einzigartig sind.
Daher weiß ich nicht, ob ich mir nicht selber nen Strick drehe, wenn ich jetzt anfange nur die benötigten Attribute/Objekte der Klasse "Monster" tief zu kopieren und den Rest halt flach. Da sehe ich einfach das Risiko, dass ich vor lauter Unterscheidungen irgendwann nur noch irgendwelche Kopierfehler suche
Wenn es also kein "Killerargument" gegen die tiefe Kopie gibt, ist das sicherlich die einfachste und sicherste Variante, soweit ich das jedenfalls sehe.

- Wenn deine Kollegen Behauptungen aufstellen, sollten sie die auch begründen können, also nachhaken.

Ich habe ohne Ende nachgehakt ;-)
Halt mit dem Ergebnis, dass sie mir auch nicht sagen konnten, wie ich das Problem anders lösen kann.
Die Hauptbegründung war halt der Ressourcenverbrauch und Performanceverlust.

Und genau um rauszufinden wie hoch dieser Verbrauch/Verlust ist, frage ich hier die Experten

Gruß
oetzi

 

[FArt]

Und genau um rauszufinden wie hoch dieser Verbrauch/Verlust ist, frage ich hier die Experten

Gruß
oetzi

Das kannst nur du beantworten, der du die Objekte kennst. Wie viele Objekte werden unnötig kopiert weil immutable? Das ist der unnötige Ressourcenverbrauch.
Fällt das ins Gewicht? Kommt darauf an wie oft du davon Gebrauch machst und wie viel Platz gesamt zur Verfügung steht.
In der Regel sollte man nur optimieren, wenn man ein Problem hat und durch die Änderunge eine spürbare (messbare) Verbesserung erzielt.

 

[oetzi]

Ja genau um die Frage geht es ja, wenn ich die so einfach beantworten könnte, würde ich nicht fragen ;-)
Was den Speicherverbrauch angeht, müsste man wohl einfach sämtliche Speicherverbrauchswerte der Attribute addieren um den Gesamtspeicherverbrauch pro Objekt zu erhalten.
Aber wie sieht es denn mit der Performance aus, wenn ich immer wieder dieses wegschreiben und einlesen über ein ByteArray mache.

Sagen wir einfach mal, dass ich anfänglich ca. 100-200 solcher Objekte mal im Speicher vorhalten würde. (Später vielleicht das 2-3 fache)

 

[FArt]

Wenn die Antwort so allgemein gültig wäre würdest du eine bekommen. Wir kennen deine Randbedingungen und die Objekte nicht.
Wenn dich das glücklicher macht: 300 Monster sind kein Problem.
Ich könnte auch sagen: 300 Monster. Nie im Leben, da geht dir der Speicher aus. Mache keinen Deep-Clone auf diese Art!
Such's dir aus.

Ok, stürzen wir uns mal auf den Designfehler: poor man's caching.

Damit möchte ich die Performance verbessern, da nicht jedesmal auf die DB zugegriffen werden muss, wenn die Basiswerte benötigt werden

Warum lässt du das nicht die DB bzw. die Persistenzschicht (Cache) optimieren? Die können das viel besser und du musst keine Klimmzüge machen.
... und mein Motto ist... optimiere bei Bedarf, nachdem Messungen vorliegen und du eine signifikante Verbesserung durch Eingriffe erwarten kannst.

 

[Landei]

Hallo Landei,

ich verstehe ehrlich gesagt nicht, was das genau mit meinem Problem zu tun hat.
Ich will doch eine Kopie von meinem Objekt haben.
Aber vielleicht habe ich den Sinn von immutable auch einfach nicht richtig verstanden

Gruß
oetzi

Von einem String brauchst du keine "tiefe" Kopie zu machen: Wenn zwei Klassen auf denselben String verweisen, ist das kein Problem, da er sich selbst nie ändert. Nun ist die Frage, ob das bei deinem Monster u.s.w. eventuell auch möglich wäre. Dazu müsste man überall da, wo früher der Monster-Zustand geändert wurde, stattdessen ein geändertes Monster zurückliefern (etwa wie String.replace, was ja auch den String nicht ändert, sondern eine geänderte Kopie zurückliefert), das Problem dabei ist, dass alle "interessierten Stellen" die Änderung auch mitbekommen müssen. Theoretisch ist das immer möglich, in manchen Fällen aber nicht besonders praktisch, nicht performant genug, und manchmal ist einfach der Aufwand zu groß, eine bestehende Struktur von veränderlich auf unveränderlich umzumodeln.

 

[oetzi]

... und mein Motto ist... optimiere bei Bedarf, nachdem Messungen vorliegen und du eine signifikante Verbesserung durch Eingriffe erwarten kannst.

das Vorgehen ist sicherlich nicht verkehrt.
Aber hättet ihr mir jetzt gesagt, dass tiefe Kopien sehr stark die Performance und oder den Speicher beeinflussen, hätte ich ja erst gar nicht auf das Pferd setzen müssen und mir das Re-Engineering gespart

@Landei: Danke für die nähere Erklärung. Aber das ganze hört sich ja schon alles andere als simpel an... Ich glaube ich werde es erstmal so lassen wie es ist (es hat ja keiner KO-Kriterien dagegen gebracht s.o. ;-) ). Und dann werde ich mal gucken was draus wird.
Vielleicht hole ich den Thread irgendwas mal wieder raus und werde von den schlechten Erfahrungen berichten ;-)

Gruß
oetzi

 

[FArt]

Aber hättet ihr mir jetzt gesagt, dass tiefe Kopien sehr stark die Performance und oder den Speicher beeinflussen, hätte ich ja erst gar nicht auf das Pferd setzen müssen und mir das Re-Engineering gespart

Na ja, auf das Pferd hättest du ja auch gar nicht erst setzen müssen. Die Frage war ja auch: sind denn die DB Zugriffe wirklich so teuer und kommen so häufig vor, dass sich dieses "Caching" lohnt? Wäre da eine reine Optimierung auf Persistenzbasis nicht von Haus aus besser gewesen?

Deswegen meinte ich erst den sauberen Weg gehen (ganz ohne "Caching") und dann an den richtigen Stellen optimieren. In sofern haben deine Kollegen bzgl. des Designfehlers schon Recht.