¿Por qué Farseer 2.x almacena temporarios como miembros y no en la pila? (.RED)

ACTUALIZACIÓN: Esta pregunta se refiere a Farseer 2.x. El nuevo 3.x no parece hacer esto.

Estoy usando Farseer Physics Engine bastante ampliamente en este momento, y he notado que parece almacenar muchos tipos de valores temporales como miembros de la clase, y no en la pila como cabría esperar.

Aquí hay un ejemplo de la Bodyclase:

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

Parece que es una optimización de rendimiento manual. ¿Pero no veo cómo esto podría ayudar al rendimiento? (En todo caso, creo que dolería al hacer que los objetos sean mucho más grandes).

Aunque en .NET los tipos de valor se almacenan en la pila, lo que resulta en un costo de asignación mínimo, sin embargo, no elimina el costo de inicialización.

En este caso, tenemos un conjunto de funciones que utilizan una o dos matrices temporales, lo que daría como resultado la inicialización de 16-32 flotantes por llamada. Si bien esto puede parecer insignificante, si los métodos se usan con la suficiente frecuencia (por ejemplo, miles y miles de veces por cuadro), la sobrecarga total puede tener un impacto significativo. Si dicha técnica se usa sistemáticamente en todos estos métodos, la sobrecarga eliminada puede ser considerable.

Si bien el uso de una técnica de este tipo elimina la capacidad de proporcionar seguridad de roscas a nivel de objeto, generalmente no es prudente proporcionar esa garantía a un nivel tan granular.

Buena pregunta. Soy un tipo bastante afilado de C # / .NET y un poco loco por el rendimiento, y esto me parece una decisión de diseño bastante extraña. Lo primero que me llama la atención es que este código no es seguro para subprocesos. No sé si eso es un problema en un sistema de Física, pero almacenar datos temporales fuera del alcance de un método suele ser una receta para el desastre.

Honestamente, si me encuentro con este tipo de código en un marco de terceros, probablemente trataría de encontrar otro marco.

El GC en el 360 básicamente solo realiza colecciones GEN 2, que son caras, por lo que las variables temporales que se crean y eliminan cada fotograma (como los objetos temporales) hacen que se ejecuten colecciones completas, lo que matará el rendimiento realmente rápido.

Sospecho que lo hicieron de esta manera para reutilizar ese objeto y no tenerlo recogido.