Performances des très grandes classes

Question

J'ai une classe appelée "simulation" et une méthode pour résoudre la simulation.

class sim
{
    void Step()
    {
    }

    other methods (20+)...
}

La classe Sim n'est instanciée qu'une seule fois au cours du programme.

La méthode des étapes est appelée dans l'ordre des millions au cours du programme.

La méthode par étapes utilise beaucoup de variables locales (100+). Aucune de ces variables locales n'est utilisée dans les autres méthodes.

Est-il préférable de faire de ces variables locales un membre de la classe ou de les garder comme locales dans Step() pour de meilleures performances ?

Answer 1

Il dépend de . Quels types de variables : types primitifs ou objets ? Si c'est le cas, votre code IL va toujours courir après leurs pointeurs. Dans le premier cas, cela dépend de l'ordre dans lequel vous y accédez et du processeur que vous visez. L'optimisation de la disposition des variables devrait figurer en bas de la liste des activités d'optimisation des performances, en particulier en C# lorsque vous dépendez de l'assemblage dans lequel votre IL est traduit.

Comme d'habitude avec les optimisations : d'abord mesure les performances pour identifier les goulets d'étranglement. Réfléchissez ensuite à ce que vous pouvez faire pour les éliminer. Jusqu'à ce que vous sachiez que vous devez faire quelque chose comme ça, écrivez votre code aussi clairement que possible : n'exposez pas inutilement les variables locales en les élevant au niveau de la classe. Et pensez à diviser ce Step() méthode : une grande méthode est difficile à comprendre et donc encore plus difficile à optimiser.

Answer 2

En règle générale, vous devez minimiser la portée des variables et ne l'augmenter que si cela s'avère absolument nécessaire. Convertir des variables locales en variables membres est un mauvais choix de conception, et nécessite donc une justification très solide.

Notez également que les variables locales n'ont un coût que si elles ont des constructeurs non triviaux. Une variable locale avec un constructeur noop ou pas de constructeur du tout n'a pas de coût de configuration, il serait donc inutile d'étendre sa portée.

Answer 3

Si certaines des variables contiennent des objets pouvant être réutilisés entre plusieurs appels de méthode, vous éviterez les frais généraux liés à l'élimination de l'ancienne instance et à la création d'une nouvelle instance à chaque appel de méthode. Par exemple, les recherches dans un conteneur d'injection de dépendances qui ne changeront pas entre les appels de méthode pourraient être "mises en cache" dans un champ.

Mais à part cela, vous n'obtiendrez probablement pas une grande augmentation des performances. Vous pouvez faire un essai et utiliser un profileur pour mesurer les performances de votre code. Un profileur peut également vous aider à identifier d'autres goulots d'étranglement dans votre code.