Quel est le coût de création de l'objet

Question

Si je dois choisir entre la méthode statique et la création d'une instance et utiliser la méthode d'instance, je choisirai toujours des méthodes statiques. mais quel est le surcoût détaillé de la création d'une instance? Par exemple, j'ai vu un DAL qui peut être fait avec des classes statiques mais ils choisissent d'en faire une instance maintenant dans la BLL à chaque appel qu'ils appellent quelque chose comme.

nouveau client(). GetData();

dans quelle mesure cela peut être mauvais?

Merci

Answer 1

La pénalité de performance devrait être négligeable. En this blog entry quelqu'un a fait un benchmark court, avec le résultat que créer 500 000 objets et les ajouter à une liste coûtent environ 1,5 secondes. Donc, puisque je suppose que new Customer().GetData(); sera appelé au plus quelques centaines de fois dans une seule fonction BLL, la pénalité de performance peut être ignorée.

Comme une note de côté, la conception ou la désignation de la classe est brisée si new Customer().GetData(); est effectivement utilisée: Si la classe Customer fournit juste les moyens d'obtenir les données, il devrait être appelé quelque chose de différent, comme CustomerReader (faute d'un meilleur nom). D'un autre côté, si Customer a un état d'instance qui représente réellement un client, GetData devrait être statique - non pour des raisons de performance, mais pour des raisons de cohérence.

Answer 2

Normalement, on ne devrait pas être trop préoccupé par la création d'objets en tête dans le CLR. L'allocation de mémoire pour le nouvel objet serait vraiment rapide (en raison de l'étape de compactage de la mémoire du garbage collector - GC). La création de nouveaux objets prendra un peu de mémoire pour l'objet et mettra un peu plus de pression sur le GC (car il devra nettoyer l'objet), mais s'il est seulement utilisé pendant une courte période, il peut être collecté dans une génération GC précoce qui n'est pas si mauvaise performance sage. Le surcoût lié aux performances serait également réduit par l'appel à une base de données.

En général, je vais prendre la décision de créer un nouvel objet pour certaines méthodes connexes ou simplement utiliser une classe statique (et des méthodes) en fonction de ce dont j'ai besoin de l'objet (par exemple En guise de note - si new Customer().GetData(); est le bon endroit pour mettre un tel code est discutable - pour moi, il semble que les données retournées sont directement liées à une instance de client sur la base de ce déclaration et pas réellement un appel à la base de données pour récupérer des données.