Чому Farseer 2.x зберігає часописи як членів, а не в стеці? (.NET)

ОНОВЛЕННЯ: Це питання стосується 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, які є дорогими, тому тимчасові змінні, які створюються та видаляються кожен кадр (як тимчасові об’єкти), викликають запуск цілих колекцій, що дуже швидко знищить продуктивність.

Я підозрюю, що вони зробили це таким чином, щоб повторно використовувати цей об'єкт, а не збирати його.