J'ai été farfouillé dans XNA et vu que l' Vector3 classe elle a été en utilisant les champs plutôt que des propriétés. J'ai essayé un rapide benchmark et a constaté que, pour un struct la différence est assez dramatique (l'ajout de deux Vecteurs ensemble 100 millions de fois, a pris 2.0 s, avec des propriétés et 1.4 s avec des champs). Pour un type de référence, la différence ne semble pas que les grandes, mais il est là.
Alors, pourquoi est-ce? Je sais qu'une propriété est compilé en get_X et set_X méthodes, ce qui entraînerait un appel de la méthode de surcharge. Cependant, n'est-ce pas simple getters/setters toujours obtenir bordée par le JIT? Je sais que vous ne pouvez pas garantir que l'équipe décide de le faire, mais sûrement, c'est assez élevé sur la liste de probabilité? Quoi d'autre est là qui sépare un champ public à partir d'une propriété au niveau de la machine?
Et une chose que je me demandais: comment agit d'une auto-mise en œuvre de la propriété (public int Foo { get; set; }) 'mieux' OO-concevoir qu'un champ public? Ou pour mieux dire: comment ces deux différents? Je sais qu'en faire une propriété est plus facile avec de la réflexion, mais quelque chose d'autre? Je parie que la réponse à ces deux questions est la même chose.
BTW: je suis à l'aide .NET 3.5 SP1 qui, je crois, correction de problèmes où les méthodes avec les structures (ou les méthodes de structs, je ne suis pas sûr) n'étaient pas en bordée, de sorte que n'est-il pas. Je pense que je suis en utilisant au moins, c'est certainement installé mais encore une fois, je suis sous Vista 64-bit SP1 qui devrait avoir DX10.1 sauf que je n'ai pas de DX10.1 ..
Aussi: ouais, j'ai fait tourner une version validée :)
EDIT: j'apprécie les réponses rapides les gars, mais j'ai indiqué que je ne connais que l'accès à la propriété est un appel de méthode, mais que je ne sais pas pourquoi, sans doute, bordée méthode est plus lent qu'un accès sur le terrain.
EDIT 2: j'ai Donc créé un autre struct qui ont utilisé explicite GetX() méthodes (o comment je n'en ai pas raté mon Java jours en tout) et qui ont effectué la même si j'ai désactivé l'in-lining sur elle (par le biais [MethodImplAttribute(MethodImplOptions.NoInlining)]) ou pas, donc, conclusion: non-static méthodes sont apparemment jamais inline, même pas sur des structures.
Je pensais qu'il y avait des exceptions, où l'équipe pourrait optmize la méthode virtuelle appel. Pourquoi ne peut-elle pas sur des structures qui ne connaissent pas l'héritage et donc un appel de méthode ne peut point d'une méthode possible, non? Ou est-ce parce que vous pouvez mettre en œuvre une interface sur elle?
C'est un peu dommage, car ça va vraiment me faire penser à l'aide de propriétés sur les performances essentielles des trucs, mais à l'aide de champs me fait me sentir sale et je pourrais tout aussi bien écrire ce que je suis en train de faire en C.
EDIT 3: j'ai trouvé ce poster sur exactement le même sujet. Sa fin, la conclusion est que l'appel de propriété ne se optimisé loin. Je pourrais aussi ai juré que j'ai lu beaucoup de fois, que de simples propriétés de lecture/définition obtiendrez en bordée, malgré callvirt dans l'IL. Donc suis-je en train de devenir folle?
EDIT 4: Reed Copsey posté la réponse dans un commentaire ci-dessous:
Re: Edit3 - voir mis à jour mon commentaire: je crois que c'est JIT x86 vs JIT x64 questions. le JIT en x64 n'est pas aussi mature. Je m'attends à de MS pour améliorer ce plus rapidement que les systèmes 64 bits sont mis en ligne chaque jour. – Reed Copsey
Et ma réponse à sa réponse:
Merci, c'est la réponse! J'ai essayé de forcer un x86 construire et à toutes les méthodes sont tout aussi rapides, et beaucoup plus rapide que la version x64. C'est très choquant pour moi en fait, je n'avais aucune idée que j'étais vivant dans l'âge de pierre sur mon système d'exploitation 64 bits.. je vais inclure votre commentaire dans ma réponse afin qu'il soit mieux. – JulianR
Merci à tous!
