'kosten' Parameter?

[BioBrause]

Hallo,
ich bin gerade dabei,
eine kleine Simulation zu basteln.
Dabei werden mir pro logic-update viele Vectorn erstellt, und dan dem gc zum fraße vorgeworfen.
Um das erstellen so vieler Objekte, welche nur für ein-zwei Rechnungen gebrauccht werden, zu verhindern bin ich jetzt dazuübergegengen, ein 'Arbeits-Object' rumzugeben.
Also anstadt:

public class foo{
Vector3 blub = new Vector3(3,3,3);
public void ba(){
Vector3 v = new Vector3();
v.add(blub);
v.fooba();
blub.foobaba();
}
}

eher

public class foo{
Vector3 blub = new Vector3(3,3,3);
public void ba(Vector3 v){
v.zero();
v.add(blub);
v.fooba();
blub.foobaba();
}
}

Meine Frage ist eigentlich rein Theoretisch, da die zeit recht klein sein dürfte, aber kosten mehr Parameter mehr zeit?
Ich vermute ein gaaaaaaaanz bisschen mehr.
Danke an alle, die sich das durchgelesen haben

 

[Marco13]

Theoretisch, vielleicht - wissen tu' ich es nicht.

Aber zur eigentlichen Intention: Ich habe auch (noch?) die Tendenz, solche vielen kleinen Objektallokationen zu vermeiden. Die waren früher mal teuer. Erstens wegen der Allokation an sich, und nicht zuletzt auch, weil der GC sich dann einen Wolf collectet hat.

Heutzutage (spätestens seit Java 7) ist das aber eigentlich nicht mehr sooo kritisch: Die JVM verwendet "Escape Analysis", um festzustellen, ob ein Objekt "eine Methode verlassen kann". Wenn es die Methode NICHT verlassen kann, wird es auf dem Stack allokiert statt auf dem Heap. D.h. es ist schnell, der GC wird nicht belastet, und Method Inlining beim JIT schmeißt noch ein paar weitere potentielle Overheads weg. Websuchen zu sowas wie "Escape Analysis Java" liefern da viele Ergebnisse.

Das soll keine Empfehlung sein, die vorgesehene "Optimierung" NICHT zu machen, nur ein Hinweis, dass man das kritisch (mit einer neuen VM) testen sollte, und es heutzutage eher mal sein kann, dass der Trade-Off zwischen "schöner API" und "effizientem Code" machmal kleiner wird, und man so einen zusätzlichen Parameter vielleicht nicht mehr einfügen muss, wenn es wirklich eine reine Optimierung sein soll, bei der man etwas zähneknirschend denkt: "Naja, anders wäre schöner..." - vielleicht lohnt es sich nicht. Nebenbei: Wenn Brian Goetz schon auffordert: Write Dumb Code könnte da ja was dran sein

 

[BioBrause]

Dann lasse ich es erstmal weg.
Sowas kann man später immer noch machen und es gefällt mir außerdem nicht.
------
Nur indirekt eine Antwort auf meine Frage, aber trotzdem interessant.
Sowohl das Interview, oder besser gesagt: der Monolog, wie auch das Stichwort "Escape Analysis".
Da lernt man wider, ohne am Morgen damit gerechnet zuhaben.
Vielen Dank und schönen tag noch (extra bis nach mitternacht gewartet, um nicht so geizig zu erscheinen :bae.

BioBrause

 

[Ullenboom]

Das fällt in der Regel überhaupt nicht ins Gewicht. Geh doch mal mit einem Profiler (wie dem NetBeans NetBeans profiler) drüber und schau, was du da für Punkte im Code ausmachen kannst.

 

[schalentier]

Die Frage ist doch eher, wie macht man es, WENN ein Objekt die Methode verlassen soll. Also:

public Vector3 doSomething( int a ) {
  Vector3 v = new Vector3( a, a, a );
  // do something
  return v;
}

vs

public void doSomething( Vector3 v, int a ) {
  v.set( a, a, a );
  // do something
}

1) ist zweifellos die schoenere API, 2) ist gefuehlt schneller (wenn korrekt benutzt, werden u.U. DEUTLICH weniger Vector3 Objekte erzeugt, also hat der GC auch deutlich weniger zu tun.

Mein Weg ist bei solchen Fragen immer: Zuerst schoene API und sollten (per Profiler gemessene) Performanceprobleme genau dort auftreten (bzw. beim GC), die performantere Methode zusaetzlich rein, die auch von der schoenen benutzt wird.

 

[Ullenboom]

In der Java-API kann man ganz gut ablesen, was man macht: Kommt es auf Performance an, macht man die Objekte mutable, wie bei StringBuilder oder Vector (siehe etwa Java 3D API). Sonst immutable, wie BigInteger, String, ... Dass BigInteger immutable ist, ist dabei ein Performance-Problem und bei vielen Berechnungen sollte man sich eine mutable Implementierung suchen.

 

[Marco13]

@schalentier: Das "schöner" ist so eine Sache - der angedeutete Code ist etwas zu suggestiv, um sich einen realen Anwendungsfall drunter vorzustellen, und im Zweifelsfall würde ich sagen, dass das komplett unterschiedliche Methoden sind.

Als Beispiel: Bei Java3D bzw. VecMath gibt es Klassen
Tuple3f
Point3f extends Tuple3f
Vector3f extends Tuple3f
Es gibt viele Methoden, für die Tuple3f reicht. Wenn man irgendwas zurückgeben muss, muss man sich für eine Implementierung entscheiden (und ggf. trotzdem Tuple3f zurückgeben). Wenn der Aufrufer aber gerade "das andere" braucht, ist das blöd.

void doSomethingA(Tuple3f t) { ... } // Modify parameter

Tuple3f doSomethingB() { ... } // Return new Tuple3f

void main()
{
    Vector3f v = new Vector3f();
    Point3f p = new Point3f();

    doSomethingA(v); // Works
    doSomethingA(p); // Works

    Tuple3f t = doSomethingB();
    // Sigh, I need a Point3f here...
    Point3f actualResult = new Point3f(t);
}

Deswegen muss man sich an manchen Stellen schon genau überlegen, was man tut. (Und wegen solcher Dinge finde ich, dass selbst vermeintlich triviale Dinge, wie "die Entwicklung allgemeiner 3D-Utility-Klassen" mit vielen sehr schweren und sehr wichtigen Designentscheidungen verbunden sind)

Ich finde das "Pattern", das z.B. bei BufferedImageOp (Java Platform SE 6) oder auch AffineTransform (Java Platform SE 6) verwendet wird, in solchen Fällen eine Erwägung wert: Man KANN das Objekt für die Ausgabe übergeben, aber wenn man 'null' übergibt, wird irgendein passendes Objekt allokiert.

So, wie die Fragestellung klang, könnte aber das dazu notwendige [c]if (param == null)[/c] zum Performance-Killer werden :joke:

 

[schalentier]

@Marco13: Ich stimm absolut zu.

Ich glaub, ich meinte auch eher eine Methode wie z.B. das Addieren von zwei Vector3. In diesem Fall ist klar, dass das Ergebnis auch ein Vector3 ist. Auch da stellt sich die Frage, ob es besser ist, fuer das Ergebnis eine neue Vector3-Instanz zu erzeugen, oder ob die "Ziel-" Instanz besser in die Methode reingegeben wird.

Beides ist imho valide und haengt stark vom konkreten Einsatzgebiet ab. Ersteres ist schoener im Sinne von OOP-Design. Zweiteres kann unter Umstaenden aber wirklich einen deutlichen Performanceboost bringen.

Schoen finde ich hier den Ansatz bei C# (glaub da hab ich das mal gesehen, oder wars C++11?), wo man vor einen Parameter noch "in" und "out" schreiben kann.

 

[Evil-Devil]

Schoen finde ich hier den Ansatz bei C# (glaub da hab ich das mal gesehen, oder wars C++11?), wo man vor einen Parameter noch "in" und "out" schreiben kann.

In C# kannst das machen. Ist dann aber nicht mehr weit entfernt von den "bösen Pointern". Gerade bei besagter Vektoren Mechanik stellt man sich doch die Frage was weniger kostet. Ich mir jedenfalls immer und die Antwort der Antworten suche ich noch immer. Unabhängig davon das man heutzutage viele der Berechnungen direkt auf der GPU ausführen kann/sollte.

 

[Marco13]

Hmja... auch ein etwas suggestives Beispiel, aber doch schon ganz gut, um das zu verdeutlichen. Wenn man eine Methode haben will, um zwei Vektoren zu addieren, könnte man machen

private static Vector3f add(Vector3f v0, Vector3f v1) 
{
    Vector3f result = new Vector3f();
    result.x = v0.x + v1.x;
    result.y = v0.y + v1.y;
    result.z = v0.z + v1.z;
    return result;
}

oder eben

private static void add(Vector3f v0, Vector3f v1, Vector3f result) 
{
    result.x = v0.x + v1.x;
    result.y = v0.y + v1.y;
    result.z = v0.z + v1.z;
}

Das "schöne" bei letzerem (insbesondere wenn es nicht um einen 3-Zeiler geht) ist, dass man dort statt Vector3f auch überall Tuple3f screiben kann, und es nach wie vor genauso (aber eben AUCH mit Point3f) funktioniert.

Diese Fragen wurden auch schonmal vor langer Zeit in einem anderen Thread so ähnlich diskutiert - dort ging es IIRC auch im vorgelagerte Fragen, auch im Zusammenhang mit der von Ullenboom angesprochenen Mutability - es gibt viele Optionen

class Vector3D
{
    public void add(Vector3D other) { /* this += other */ } // oder
    public Vector3D add(Vector3D other) { /* return this + other */ } // oder
    public static Vector3D add(Vector3D v0, Vector3D v1) { /* return v0+v1 */ } // oder
    public static void add(Vector3D v0, Vector3D v1, Vector3D sum) { /* sum = v0+v1 */ } // oder
    // oder was ganz anderes...?
}

und man könnte schon lange darüber streiten, welche davon aus Design-Sicht und abhängig von den gesetzen Prioritäten nun die "beste" ist - dazu kommt aber auch, dass sich die Gewichtung und Bedeutung vermeintlich objektiv bewertbarer Kriterien (wie ~"Performance durch wenige Objektallokationen") mit verschiedenen JVMs ändern kann.