Почему Farseer 2.x хранит временные файлы как члены, а не в стеке? (.СЕТЬ)

ОБНОВЛЕНИЕ: Этот вопрос относится к Farseer 2.x. Более новый 3.x, кажется, не делает этого.

В настоящее время я довольно широко использую Farseer Physics Engine, и я заметил, что он, похоже, хранит много временных типов значений в качестве членов класса, а не в стеке, как можно было бы ожидать.

Вот пример из Bodyкласса:

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

Похоже, это оптимизация производительности вручную. Но я не понимаю, как это может помочь производительности? (Во всяком случае, я думаю, что было бы больно делать объекты намного больше).

Хотя типы значений в .NET хранятся в стеке, что приводит к минимальной стоимости размещения, это, тем не менее, не устраняет стоимость инициализации.

В этом случае у нас есть набор функций, использующих одну или две временные матрицы, что приведет к инициализации 16-32 операций с плавающей запятой за вызов. Хотя это может показаться незначительным, если методы используются достаточно часто (скажем, тысячи и тысячи раз за кадр), общая нагрузка может оказать существенное влияние. Если такой метод используется систематически во всех таких методах, устраненные накладные расходы могут быть значительными.

Хотя использование такого метода исключает возможность обеспечения безопасности потоков на уровне отдельных объектов, в общем случае неразумно предоставлять такую ​​гарантию на таком детальном уровне.

Хороший вопрос. Я довольно проницательный парень из C # / .NET и немного псих, и это кажется мне довольно странным дизайнерским решением. Первое, что бросается в глаза, это то, что этот код никоим образом не безопасен для потоков. Я не знаю, является ли это проблемой в физической системе, но хранение временных данных вне области действия метода часто приводит к катастрофе.

Честно говоря, если бы я регулярно сталкивался с такого рода кодом в сторонних фреймворках, я, вероятно, попытался бы найти другой фреймворк.

GC на 360 в основном делает только коллекции GEN 2, которые дороги, поэтому временные переменные, которые создаются и удаляются каждый кадр (например, временные объекты), приводят к запуску целых коллекций, что очень быстро снижает производительность.

Я подозреваю, что они сделали это таким образом, чтобы повторно использовать этот объект, а не собирать его.