Pourquoi Farseer 2.x stocke-t-il les temporaires en tant que membres et non sur la pile? (.NET)

MISE À JOUR: Cette question se réfère à Farseer 2.x. Le nouveau 3.x ne semble pas faire cela.

J'utilise Farseer Physics Engine pour le moment, et j'ai remarqué qu'il semble stocker beaucoup de types de valeurs temporaires en tant que membres de la classe, et non sur la pile comme on pourrait s'y attendre.

Voici un exemple de la Bodyclasse:

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

Cela ressemble à une optimisation manuelle des performances. Mais je ne vois pas comment cela pourrait éventuellement améliorer les performances? (Si quoi que ce soit, je pense que cela ferait mal en rendant les objets beaucoup plus gros).

Bien que les types de valeurs .NET soient stockés sur la pile, ce qui entraîne un coût d'allocation minimal, cela n'élimine cependant pas le coût d'initialisation.

Dans ce cas, nous avons un ensemble de fonctions utilisant une ou deux matrices temporaires, ce qui entraînerait l'initialisation de 16 à 32 flottants par appel. Bien que cela puisse sembler insignifiant, si les méthodes sont utilisées assez souvent (par exemple, des milliers et des milliers de fois par trame), la surcharge totale peut avoir un impact significatif. Si une telle technique est utilisée systématiquement dans toutes ces méthodes, les frais généraux éliminés peuvent être considérables.

Bien que l'utilisation d'une telle technique élimine la possibilité d'assurer la sécurité des threads au niveau de chaque objet, il n'est généralement pas judicieux de fournir cette garantie à un niveau aussi granulaire.

Bonne question. Je suis un gars C # /. NET assez pointu et un peu fou de la performance, et cela me semble une décision de conception plutôt étrange. La première chose qui me saute aux yeux est que ce code n'est en aucun cas sûr pour les threads. Je ne sais pas si c'est un problème dans un système de physique, mais le stockage de données temporaires en dehors du champ d'application d'une méthode est souvent une recette pour un désastre.

Honnêtement, si je rencontrais régulièrement ce type de code dans un framework tiers, j'essaierais probablement de trouver un autre framework.

Le GC sur le 360 ​​ne fait que des collections GEN 2, qui sont chères, donc les variables temporaires qui sont créées et supprimées à chaque image (comme les objets temporaires) entraînent l'exécution de toutes les collections, ce qui réduira les performances très rapidement.

Je soupçonne qu'ils l'ont fait de cette façon pour réutiliser cet objet et ne pas le récupérer.