Listener und Performance

[manuche]

Hallo.

Ich beginne grade als Übung eine 2D Physikengine in Java umzusetzen... Dazu baue ich mir erstmal eine Vektorklassen zusammen. Ganz stumpf beinhaltet diese erstmal eine x y Koordinate von Anfang und Endpunkt... Darüber hinaus soll noch eine Membervariable für die Länge implementiert sein.
Wenn jetzt ein x oder y Wert geändert wird kann sich unter Umständen auch die Länge des Vektors ändern!
Meine Idee war nun, einen Listener für die Variablen zu erstellen, um gegebenfalls die Länge zu aktualisieren.
Ist diese sinnvoll bzw wenn performant genug? Schliesslich kann ich die Länge ja auch ausrechnen falls ich die Variable abfrage.
Wenn sich das aus Sicht der Performance nichts nimmt würde ich halt zum Listener tendieren.

gruß manuche

 

[Illuvatar]

Naja, also - logisch wäre es, die Länge in setX bzw. setY neu zu berechnen. Wenn du es erst in getLength machst, kann es eventuell ein kleines bisschen performanter sein. Sicher aber nicht so viel, dass man es merkt - außerdem wäre dann die Frage ob du das in getLength immer berechnest, oder ob du dann halt irgendwie speicherst ob du berechnen musst und so...

 

[Marco13]

Das ist ein bißchen heikel. Selbst in der offiziellen javax.vecmath-Bibliothek wurde (vermutlich (damals noch) aus Effizienzgründen) das (eigentlich) nicht akzeptable Designverbrechen begangen, die x,y,z-Komponenten bei einem Vector3f als public float umzusetzen.

Gerade bei der Berechnung der Länge wird es besonders kritisch: Es ist SEHR, SEHR aufwändig, die Länge zu berechnen (Wurzel ziehen). Wenn du z.B. eine Simulation schreibst, wo von 1000 Punkten in einem Schritt 1000 mal die x,y-Koordinaten geändert werden, willst du mit Sicherheit nicht 1 Million mal irgendwelche Listener benachrichtigen und Längen berechnen - zumal die Längen ja vielleicht garnicht gebraucht werden!

Ich würde dir empfehlen, die Länge nicht als member zu speichern, sondern nur eine Methode "getLength" anbieten, die die Länge jedes Mal neu ausrechnet. Den Wert "zwischenzuspeichern" (wenn er mehrfach benötigt wird, und sich zwischendurch nichts ändert) könnte ggf. der Aufrufer übernehmen.

Eine mögliche Alternative wäre vielleicht (!!! das muss man sich überlegen !!!) die Länge als member zu speichern, und bei jeder Änderung der Koordinaten auf "-1" zu setzen (quasi um zu signalisieren: "Die Länge ist ungültig"). In der Methode getLength wird die Länge dann NUR neu berechnet, wenn sie -1 ist, und ansonsten die schon berechnete Länge zurückgegeben.

Natürlich kann (und sollte) man auch die verschiedenen Ansätze mal implementieren, und bei einem praktischen Beispiel mit einem Profilerlauf feststellen, wo die meiste Rechenzeit verbraten wird.

Aber selbst bei der grundlegenderen Frage, ob so was Primitives wie ein 2D-Vektor überhaupt Listener haben sollte, sollte man sich Gedanken machen...

Ein Ansatz, der im ersten Moment ein bißchen absurd klingt, den man aber evtl. auch in Erwägung ziehen könnte, wäre sowas wie eine Klasse "Vector2D" und eine Klasse "Vector2DWithListeners extends Vector2D" zu erstellen (oder beides über Interfaces), und nur letztere bietet die Möglichkeit, Listener anzuhängen, aber das ist ein ziemlich gewagter und in keinster Forum durchdachter Spontan-Gedanke.

 

[manuche]

Klar das wäre der einfachste Weg...
Also wäre ein extra Listener dafür zuviel Ballast?

 

[Marco13]

Auch auf die Gefahr hin, dass du den obigen Beitrag noch nicht gelesen hattest: Bei dem Wort "Ballast" fällt mir auch noch ein, dass es ja ggf. SEHR viele Vectoren geben wird. Vielleicht auch viele, die nur für Zwischenrechnungen verwendet werden. Wenn man in jedem Vector eine ArrayList mit Listenern speichert, dann braucht ein Vector "standardmäßig" schonmal nicht 2*4+x = 8+x bytes (für ein Objekt (x) und 2 floats) sondern >2*4+4+4+10*4+x = 56+x bytes (für ein Objekt (x), eine Referenz auf die Liste, eine Referenz auf den Array, 10 Array-Einträge, und noch ein paar Kleinigkeiten). Je nach Zusammenhang und Art der Anwendung könnte das ja auch von Bedeutung sein....

EDIT: Aber um das nochmal klar zu sagen: Ich will dir die Listener nicht "ausreden", sondern nur verdeutlichen, dass es - abhängig davon, was du vorhast!!! - einige Punkte geben KÖNNTE, die dagegen sprechen KÖNNTEN.

 

[BjörnBu]

Hmm

Den "schönsten" Verktor fände ich den, der ohne memer für die Länge aus kommt. Am performatesten dürfte das sein, was die Länge so selten wie möglich berechnet und das ist wohl Marcos Idee die Länge bei Änderungen auf -1 (o.ä.) zu setzen.

Initial wird der Wert auch auf -1 gesetzt und nur beim Aufruf getLength() berechnet, wenn er grade -1 ist.

Halte die Idee für sehr gut und wenn ich nichts übersehe auch quasi-optimal. Du Berechnest die Länge so immer nur, wenn unbedingt notwendig und hast nur ein einzelnen member mehr als unbedingt notwendig, der Speicher braucht.

Die einzige Situation, die mir jetzt einfällt, in der das nicht optimal ist, ist wenn es sehr viele Vektoren gibt aber unglaublich selten die Länge gefragt ist. Dann könnte die Lösung ganz ohne member minimal besser abschneiden.

Eine Situation wo der Listener "gewinnt" fällt mir spontan gar nicht ein.

 

[Marco13]

Die einzige Situation, die mir jetzt einfällt, in der das nicht optimal ist, ist wenn es sehr viele Vektoren gibt aber unglaublich selten die Länge gefragt ist. Dann könnte die Lösung ganz ohne member minimal besser abschneiden.

"Besser" in bezug auf was? Effizienter ist es wohl auch dann nicht, aber ... ist eben einer der vielen Fälle, wo man einen Tradeoff zwischen Rechenzeit und Speicherverbrauch hat.... Deswegen auch der Hinweis, dass man die Anwendungsszenarien kennen und (selbst dann noch) ein paar Profilerläufe machen sollte...

 

[Illuvatar]

Ich an deiner Stelle würde es so machen, wie es BjörnBu jetzt auch geschrieben hast. Einzig allein in Bezug auf den Speicherverbrauch könnte es noch etwas besser gehen. Falls du später trotzdem noch irgendwelche Probleme haben solltest, kann dir ein Profiler am Besten sagen, wo die liegen.

 

[Tobias]

Zum Thema scheint alles gesagt, deshalb nur noch ein Wort zu deiner Signatur:

Das hängt davon ab, wie weiß und wie teuer der Teppich ist.

 

[FArt]

Wie Illuvatar:
mach dir Gedanken um die Performance, wenn es Probleme gibt. Ziehe ein sauberes Design vor.

Das Observerpattern setzt man sinnvoll ein, wenn zwei voneinander getrennte Bereiche (Objekte) dieses Verhalten realisieren müssen. In einem Objekt mit allen Attributen ist das unnötig. Die Optimierungen, wann und wie die Länge berechnet werden soll, ob ein Flag für die Ungültigkeit eingeführt werden soll usw. kannst du nach Bedarf übernehmen.

Die 3 Grundregeln des Optimierens: optiemiere spät, optimiere spät, optimiere spät. Danach zählt: optimiere bei Bedarf, nur bei konkreten Problemen und nur dann, wenn eine signifikante Verbesserung dadurch zu erwarten ist.