Por que o Farseer 2.x armazena temporários como membros e não na pilha? (.INTERNET)

ATUALIZAÇÃO: Esta pergunta se refere ao Farseer 2.x. O 3.x mais recente não parece fazer isso.

Atualmente, estou usando o Farseer Physics Engine bastante extensivamente e notei que parece armazenar muitos tipos de valor temporário como membros da classe, e não na pilha, como seria de esperar.

Aqui está um exemplo da 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;
}

Parece que é uma otimização de desempenho manual. Mas não vejo como isso poderia ajudar no desempenho? (Se alguma coisa eu acho que machucaria fazendo objetos muito maiores).

Embora no .NET os tipos de valor estejam armazenados na pilha, resultando em um custo mínimo de alocação, ele não elimina o custo de inicialização.

Nesse caso, temos um conjunto de funções usando uma ou duas matrizes temporárias, o que resultaria na inicialização de 16 a 32 pontos flutuantes por chamada. Embora isso possa parecer insignificante, se os métodos forem usados ​​com bastante frequência (digamos, milhares e milhares de vezes por quadro), a sobrecarga total pode ter um impacto significativo. Se essa técnica for usada sistematicamente em todos esses métodos, a sobrecarga eliminada poderá ser considerável.

Embora o uso dessa técnica elimine a capacidade de fornecer segurança de rosca em um nível por objeto, geralmente não é aconselhável fornecer essa garantia em um nível granular.

Boa pergunta. Eu sou um cara c # / .NET muito afiado e um pouco maluco por desempenho, e isso me parece uma decisão de design bastante estranha. A primeira coisa que me impressiona é que esse código não é de forma alguma seguro para threads. Não sei se isso é um problema em um sistema de física, mas armazenar dados temporários fora do escopo de um método geralmente é uma receita para um desastre.

Honestamente, se eu encontrasse esse tipo de código regularmente em uma estrutura de terceiros, provavelmente tentaria encontrar outra estrutura.

O GC no 360 basicamente faz apenas coleções GEN 2, que são caras, então variáveis ​​temporárias que são criadas e removidas a cada quadro (como objetos temporários) fazem com que coleções inteiras sejam executadas, o que prejudica o desempenho muito rápido.

Eu suspeito que eles fizeram dessa maneira para reutilizar esse objeto e não o coletaram.