Lorsque, si jamais, est plus rapide de passer des arguments comme des arguments à une méthode statique plutôt que de disposer de la méthode non statique et d'accéder aux mêmes valeurs via des membres d'instance. Supposons que la méthode accède à ces membres dans une mode en lecture seule.
Toutes les autres choses étant égales, appeler une méthode statique est légèrement plus rapide que d'appeler une méthode d'instance.
Toutes les autres choses étant égales, appelant une méthode sans arguments est légèrement plus rapide que d'appeler un avec des arguments.
considérer: par rapport à ce code équivalent: Je ne peux pas penser à une situation réelle dans laquelle ce type d'optimisation ajouterait vraiment une valeur, mais comme une expérience de pensée (pour ceux qui aiment discuter de ce genre de choses), y a-t-il vraiment un avantage, et si oui, combien d'arguments (de quoi Types, etc.) Inclinez l'équilibre dans l'autre sens? Tout autre facteur joue-t-il à l'examen de cela? L'accès à la méthode statique _Toutez comme une variable locale plutôt qu'un champ, par exemple.
3 Réponses :
Il y a une prestation de performance possible je peux thnk de (pour une méthode non virtuelle): la méthode statique n'a pas besoin de tester une référence pour Nullity d'abord (pour lancer un Je ne pense pas cela donne actuellement un avantage, mais c'est un possible. Je ne suis pas sûr qu'il appliquerait dans votre exemple particulier, mais il est difficile de voir comment cela s'appliquerait dans tous les cas où vous vouliez utiliser la valeur. NullReferenceException le cas échéant).
Dans votre cas (je suppose que l'échantillon de code serait dans la catégorie de la classe) statique et non statique n'aura aucune différence de vitesse. Cela vient de votre lien:
Donc, il n'ya aucun sens pour le rendre statique pour un boost de vitesse.
Prenez également en compte que les valeurs fournies dans votre page liée sont de .NET 1.1 et voies obsolètes.
Un point intéressant, bien que cela ne s'applique que lorsque des méthodes sont inlinées. L'exemple que j'ai utilisé serait probablement des méthodes plus vastes mais plus grandes (ou celles ayant des types de valeur en tant qu'arguments, IIRC) ne seraient pas induites auquel cas l'appel statique coûte 6.1N et les coûts d'appel d'instance 6.8NS.
Selon le lien que vous avez, l'appel d'instance serait 6,2 ns au lieu de 6.1NS pour le statique. En fait, il n'y a pas non plus de chiffres que cela suppose que cela serait trop compensé par le paramètre supplémentaire, ce qui signifie que la version statique est probablement même légèrement plus lente.
Juste pour clarifier: c'est un appel de cet instance
@ Drew - Fonctions avec des types de valeur Comme les arguments sont correctement inlinés à partir de .NET 3.5 SP1. @ Foxfire - corrigez-moi si je me trompe, mais je pense qu'une méthode d'instance a une référence implicite, cette référence est transmise à cet argument, où il est explicite dans la méthode statique, mais ils prennent tous les deux 1 argument.
Je suppose que cela pourrait être un appel d'instance. Merci d'avoir souligné cette distinction comme un facteur.
@Julianr - Je crois que tu as raison. Les appels d'instance passent l'adresse de la cible sur la pile d'exécution, au moins dans le modèle IL. Que se passe-t-il une fois que le Jit a eu son mot à dire est une histoire différente. Il se peut que la référence cible soit déjà en-enregistrée, auquel cas il n'est pas passé en tant que tel.
@Julianr est probablement correct. D'autre part, comme indiqué déjà, je ne prendrais pas littéralement les nombres concrets de toute façon. Comme dit qu'ils sont obsolètes (Pentium III sur .NET 1.1) et même l'AUTOR dit qu'ils sont très problématiques. En fait, ils suggèrent que la méthode non inline la plus rapide serait un appel virtuel (5.4ns) !! Et tout le monde peut voir que cela n'a aucun sens pour de vraies applications.
@ Drew Noakes Tout comme Info: Étant donné que .NET 3.5 Les types de valeur sont également inlinés pour le temps d'exécution 32 bits (avant qu'ils n'aient été inlinés que sur x64).
Je ne suis pas sûr de la statique des performances entre méthodes statiques et méthodes d'instance.
Mais je pense que la décision doit être prise si vous le faites comme une méthode statique ou une méthode d'instance sur la base de la conception de l'objet. Si, en appelant votre méthode, l'état de l'objet n'est pas altéré, alors vous devez faire cette méthode en tant que méthode statique (méthode pour le type, non pour une instance perturbée du type).
+1 Bonne question. Lorsque vous exécutez une analyse de code sur votre code dans VS, vous obtenez une erreur CA1822 si vos méthodes de votre classe peuvent être marquées comme statique. Cela m'aime toujours et je me demande vraiment s'il y a un avantage.
@BFree - Si vous suivez le lien que j'ai inclus dans la question, vous pouvez voir que l'appelant une méthode statique est toujours légèrement plus rapide. En IL, l'appelant n'a pas à repousser une référence à la cible sur la pile (le JIT annule probablement cela) et l'EE n'a pas à vérifier cette cible pour la nullabilité.
Oui, il y a un gain de performance, mais vous n'êtes probablement pas le voir avant d'appeler la méthode dans une boucle à des centaines de milliers de fois. Optimisation prématurée.
Il améliore mes performances de compréhension si la première considération pour effectuer une méthode statique ou non est si elle appartient conceptuellement au type d'objet et non une instance d'un objet. Par exemple, si l'objet chien a une méthode d'aboie statique (). Je vais chercher un commentaire avec une explication.
@Darren - convenu. Je demande cela comme plus d'après-midi (pour moi, quand même) pensait à expérimenter ceux qui trouvent le fonctionnement intérieur de la langue / EE / JIT / Type-System intéressant.
"Je ne peux pas penser à une situation du monde réel où ce type d'optimisation ajouterait vraiment une valeur" - Ni-I. C'est la micro-optimisation. Et @bfree - Nous éteignons MarkMembersasStatic dans notre projet FXCOP. Les méthodes statiques ne jouent pas bien à l'injection de test de l'unité et de dépendance, non plus.