Perché Farseer 2.x memorizza i provvisori come membri e non nello stack? (.NETTO)

AGGIORNAMENTO: questa domanda si riferisce a Farseer 2.x. Il nuovo 3.x non sembra farlo.

Al momento sto usando Farseer Physics Engine abbastanza ampiamente e ho notato che sembra memorizzare molti tipi di valore temporanei come membri della classe e non nello stack come ci si potrebbe aspettare.

Ecco un esempio dalla 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;
}

Sembra un'ottimizzazione manuale delle prestazioni. Ma non vedo come questo possa aiutare le prestazioni? (Semmai penso che danneggerebbe facendo oggetti molto più grandi).

Sebbene in .NET i tipi di valore siano archiviati nello stack, con un costo di allocazione minimo, tuttavia non elimina il costo di inizializzazione.

In questo caso abbiamo un set di funzioni che usano una o due matrici temporanee, il che comporterebbe l'inizializzazione di 16-32 float per chiamata. Anche se questo può sembrare insignificante, se i metodi sono usati abbastanza spesso (diciamo, migliaia e migliaia di volte per frame), l'overhead totale può avere un impatto significativo. Se una tale tecnica viene utilizzata sistematicamente in tutti questi metodi, il sovraccarico eliminato può essere considerevole.

Mentre l'uso di una tale tecnica elimina la capacità di fornire la sicurezza della filettatura a livello di oggetto, in genere non è saggio fornire tale garanzia a tale livello granulare.

Buona domanda. Sono un tipo C # /. NET piuttosto acuto e un po 'fuori di testa per le prestazioni, e questa mi sembra una decisione piuttosto strana. La prima cosa che mi viene in mente è che questo codice non è sicuro per i thread. Non so se questo è un problema in un sistema di fisica, ma la memorizzazione di dati temporanei al di fuori dell'ambito di un metodo è spesso una ricetta per il disastro.

Onestamente, se incontrassi regolarmente questo tipo di codice in un framework di terze parti, probabilmente proverei a trovare un altro framework.

Il GC sul 360 fondamentalmente esegue solo raccolte GEN 2, che sono costose, quindi le variabili temporanee che vengono create e rimosse da ogni fotogramma (come gli oggetti temp) fanno funzionare un'intera raccolta, il che uccide le prestazioni molto velocemente.

Ho il sospetto che lo abbiano fatto in questo modo per riutilizzare quell'oggetto e non averlo raccolto.