Effets de la portée variable sur la performance ? (C#)

Question

Supposons que nous ayons 3 classes :

Classes de lieu, de contact et de numéro de téléphone.

Sous la classe Place, je veux avoir une classe Contact mais il est préférable de garder la classe PhoneNumber sous la classe Contact. Ainsi, dans la classe Place, il est plus logique d'atteindre le numéro de téléphone en obtenant d'abord l'objet Contact, puis le numéro de téléphone sous l'objet Contact.

Si j'ai souvent besoin d'obtenir l'objet PhoneNumber à partir d'un objet Place, le fait de conserver la classe PhoneNumber sous la classe Contact (Place.Contact.PhoneNumber) au lieu d'insérer directement cet objet sous la classe Place (Place.Contact) pose-t-il des problèmes de performance ?

La raison pour laquelle je pose cette question est que ce type de problèmes de portée a de nombreux effets sur les performances en JavaScript. Cela vaut-il la peine d'être aussi paranoïaque sur les relations entre la portée des variables et les performances en C# ?

Nous vous remercions.

Answer 1

En C#, vous ne verrez pas beaucoup de problèmes de performance liés à des getters et setters de propriété triviaux* comme celui-ci. Cependant, sans profilage, il est impossible de dire si cela vous posera un problème.

Dans la plupart des cas, cependant, les constructions de graphes d'objets ne créent jamais de problèmes de performance en C# comme ils peuvent le faire en JavaScript.

---

* Propriétés qui renvoient simplement une référence à un objet existant et n'ont pas de logique supplémentaire.

Answer 2

Cela aura un effet sur les performances, mais ne posera pas de problème. Le compilateur just-in-time compile les accès aux membres en calculs de pointeurs directs (après avoir calculé la disposition de chaque classe lors du chargement de l'assemblage), de sorte que l'accès aux membres est beaucoup plus rapide en C# qu'il ne l'est en JavaScript.

Answer 3

À moins qu'il ne s'agisse de la dernière étape de votre liste de choses à essayer pour que votre programme tourne un peu plus vite, et par "un peu" je veux dire "minuscule" dans ce cas, je ne m'en préoccuperais pas.

Pour répondre d'abord à votre question, oui, cela peut avoir un impact sur les performances du code. Le code pour lire ref.ref.prop nécessitera un peu plus de code que ref.prop , évidemment.

Toutefois, cela rendra très petit sur les performances du code, et à moins que vous ne lisiez cette propriété 2 niveaux plus bas plusieurs fois dans une boucle, et que vous ne fassiez pas grand-chose d'autre d'utile, l'effet d'avoir 1 ou 2 niveaux sur ce scénario particulier sera éclipsé par tout autre code que vous pourriez être en train d'exécuter.

Dans tous les cas, la règle générale est d'écrire le code de la manière la plus évidente, la plus simple et la plus compréhensible, afin qu'il soit avant tout facile à écrire et à maintenir, ce qui, à long terme, entraînera moins de bogues.

À un moment donné, si votre programme a un problème de performance et que vous découvrez que ce code particulier est le morceau de code qui prend le plus de temps, à ce moment-là, puis Ce n'est qu'à ce moment-là que vous essayez d'optimiser ce code.