Warum speichert Farseer 2.x Provisorien als Mitglieder und nicht auf dem Stapel? (.NETZ)

UPDATE: Diese Frage bezieht sich auf Farseer 2.x. Das neuere 3.x scheint dies nicht zu tun.

Ich verwende Farseer Physics Engine im Moment ziemlich häufig und habe festgestellt, dass es viele temporäre Werttypen als Mitglieder der Klasse zu speichern scheint und nicht wie erwartet auf dem Stapel.

Hier ist ein Beispiel aus der BodyKlasse:

private Vector2 _worldPositionTemp = Vector2.Zero;

private Matrix _bodyMatrixTemp = Matrix.Identity;
private Matrix _rotationMatrixTemp = Matrix.Identity;
private Matrix _translationMatrixTemp = Matrix.Identity;

public void GetBodyMatrix(out Matrix bodyMatrix)
{
    Matrix.CreateTranslation(position.X, position.Y, 0, out _translationMatrixTemp);
    Matrix.CreateRotationZ(rotation, out _rotationMatrixTemp);
    Matrix.Multiply(ref _rotationMatrixTemp, ref _translationMatrixTemp, out bodyMatrix);
}

public Vector2 GetWorldPosition(Vector2 localPosition)
{
    GetBodyMatrix(out _bodyMatrixTemp);
    Vector2.Transform(ref localPosition, ref _bodyMatrixTemp, out _worldPositionTemp);
    return _worldPositionTemp;
}

Es sieht so aus, als wäre es eine Leistungsoptimierung von Hand. Aber ich sehe nicht ein, wie dies möglicherweise zur Leistung beitragen könnte? (Wenn überhaupt, würde es meiner Meinung nach weh tun, wenn Objekte viel größer gemacht würden).

Obwohl in .NET Werttypen auf dem Stapel gespeichert sind, was zu minimalen Zuordnungskosten führt, werden die Initialisierungskosten jedoch nicht eliminiert.

In diesem Fall haben wir eine Reihe von Funktionen, die eine oder zwei temporäre Matrizen verwenden, was zur Initialisierung von 16-32 Floats pro Aufruf führen würde. Dies mag zwar unbedeutend erscheinen, aber wenn die Methoden häufig genug verwendet werden (z. B. Tausende und Abertausende Male pro Frame), kann der Gesamtaufwand einen bedeutenden Einfluss haben. Wenn eine solche Technik systematisch für alle diese Methoden verwendet wird, kann der eliminierte Overhead beträchtlich sein.

Während die Verwendung einer solchen Technik die Möglichkeit beseitigt, Gewindesicherheit auf Objektebene bereitzustellen, ist es im Allgemeinen unklug, diese Garantie auf einer solchen granularen Ebene bereitzustellen.

Gute Frage. Ich bin ein ziemlich scharfer C # /. NET-Typ und ein bisschen eine Performance-Nuss, und das scheint mir eine ziemlich seltsame Designentscheidung zu sein. Das erste, was mir auffällt, ist, dass dieser Code in keiner Weise threadsicher ist. Ich weiß nicht, ob dies ein Problem in einem Physiksystem ist, aber das Speichern temporärer Daten außerhalb des Anwendungsbereichs einer Methode ist oft ein Rezept für eine Katastrophe.

Wenn ich regelmäßig auf diese Art von Code in einem Framework eines Drittanbieters stoßen würde, würde ich wahrscheinlich versuchen, ein anderes Framework zu finden.

Der GC auf dem 360 führt im Grunde nur GEN 2-Sammlungen aus, die teuer sind. Daher führen temporäre Variablen, die in jedem Frame erstellt und entfernt werden (wie temporäre Objekte), dazu, dass eine ganze Sammlung ausgeführt wird, was die Leistung sehr schnell beeinträchtigt.

Ich vermute, sie haben es auf diese Weise getan, um dieses Objekt wiederzuverwenden und nicht sammeln zu lassen.