Dlaczego Farseer 2.x przechowuje pliki tymczasowe jako członków, a nie na stosie? (.NETTO)

AKTUALIZACJA: To pytanie dotyczy Farseer 2.x. Nowsza wersja 3.x tego nie robi.

W tej chwili używam Farseer Physics Engine dość szeroko i zauważyłem, że wydaje się, że przechowuje wiele tymczasowych typów wartości jako członków klasy, a nie na stosie, jak można się spodziewać.

Oto przykład z Bodyklasy:

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;
}

Wygląda na ręczną optymalizację wydajności. Ale nie rozumiem, w jaki sposób mogłoby to poprawić wydajność? (Jeśli cokolwiek, myślę, że zaszkodziłoby, gdyby obiekty były znacznie większe).

Chociaż typy wartości .NET są przechowywane na stosie, co powoduje minimalny koszt alokacji, nie eliminuje to jednak kosztu inicjalizacji.

W tym przypadku mamy zestaw funkcji wykorzystujących jedną lub dwie macierze tymczasowe, co spowodowałoby inicjalizację 16-32 liczb zmiennoprzecinkowych na wywołanie. Chociaż może się to wydawać nieistotne, jeśli metody są stosowane wystarczająco często (powiedzmy tysiące i tysiące razy na ramkę), całkowity narzut może mieć znaczący wpływ. Jeżeli taka technika jest stosowana systematycznie we wszystkich takich metodach, wyeliminowane koszty ogólne mogą być znaczne.

Chociaż zastosowanie takiej techniki eliminuje możliwość zapewnienia bezpieczeństwa gwintu na poziomie poszczególnych obiektów, generalnie nierozsądne jest zapewnienie tej gwarancji na tak szczegółowym poziomie.

Dobre pytanie. Jestem dość ostrym facetem C # / .NET i trochę wariatem wydajności, co wydaje mi się dość dziwną decyzją projektową. Pierwszą rzeczą, która mnie zaskakuje, jest to, że ten kod nie jest w żaden sposób bezpieczny dla wątków. Nie wiem, czy jest to problem w systemie fizyki, ale przechowywanie danych tymczasowych poza zakresem metody jest często receptą na katastrofę.

Szczerze mówiąc, gdybym regularnie spotykał się z tego rodzaju kodem w frameworku innej firmy, prawdopodobnie spróbowałbym znaleźć inny framework.

GC na 360 w zasadzie robi tylko kolekcje GEN 2, które są drogie, więc zmienne tymczasowe, które są tworzone i usuwane z każdej ramki (jak obiekty tymczasowe) powodują, że działają całe kolekcje, co bardzo szybko zabija wydajność.

Podejrzewam, że zrobili to w ten sposób, aby ponownie użyć tego obiektu i nie odebrać go.