ElementName contre RelativeResource?

Question

Qu'est-ce que les TextBlocks suivantes de coûts plus Manchettes performance:

<Window  
  x:Name="Me"
  x:Class="MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  xmlns:src="clr-namespace:WpfApplication1" 
  Title="MainWindow">
  <StackPanel>
    <TextBlock Text="{Binding Title, ElementName=Me}"/>
    <TextBlock Text="{Binding Title, RelativeSource={RelativeSource AncestorType={x:Type src:MainWindow}}}"/>
  </StackPanel>    
</Window>

Je suis sûr que ma question peut prendre différentes lorsque les TextBlocks sont dans un haut niveau d'imbrication ayant de nombreux frères et soeurs et ancêtres.

Considérations

(basé sur des pensées personnelles uniquement, je peux me tromper dans chacun en particulier!):

• ElementName :

  • peut rechercher et comparer élément courant à plus de contrôle, à travers tous ses enfants, frères et sœurs, oncles et grands-oncles, y compris les ancêtres (peut-être il y a une table de hachage de tous les noms enregistrés?)
  • Obtenir une propriété Name d'un contrôle devrait coûter moins de performances que d'appeler GetType.
  • La comparaison d'une chaîne est moins cher que de comparer les types, surtout quand on sait que la plupart des contrôles n'ont même pas leur jeu de Name.

• FindAncestor :

  • Est-ce que itérer à travers les ancêtres, pas de les oncles siblingls, etc. 'cousins'.
  • La plupart des utilisations probables GetType pour déterminer le type ancêtre; Les coûts GetType plus de performance alors simple getter de propriété Name (peut-être sont différents partenaires au développement?)

Answer 1

Il est généralement une terrible idée d'essayer de répondre à ce genre de chose en faisant valoir à propos que vous pensez sera plus rapide. Il vaut beaucoup mieux pour construire une expérience pour mesurer.

Je modifié votre configuration un peu - je mets le XAML pertinent dans un UserControl et lié à la propriété Name depuis UserControl ne dispose pas d'une propriété Title. J'ai alors écrit un code pour créer une nouvelle instance de contrôle et l'ajouter à l'interface utilisateur, et a utilisé le Stopwatch pour mesurer le temps de construction et le charger. (Je commence le moment juste avant la construction du contrôle de l'utilisateur, et je me arrête juste après le contrôle de l'utilisateur pose son événement Loaded.)

Je lance ce code d'une DispatcherTimer 20 fois par seconde pour que je puisse prendre beaucoup de mesures dans l'espoir de réduire l'erreur expérimentale. Afin de minimiser les distorsions dues au débogage et le code de diagnostic, je suis en cours d'exécution dans une version Release, et je ne calculer et imprimer la moyenne après 2000 itérations terminées.

Après 2000 itérations, la moyenne approche ElementName 887us.

Après 2000 itérations, la moyenne approche RelativeSource 959us.

ElementName est, dans cette expérience particulière, un peu plus rapide que RelativeSource. Chargement d'un UserControl trivial avec juste un Grid et un TextBlock où il n'y a qu'un seul élément nommé, l'aspect approche de ElementName de prendre 92% du temps de charge que l'approche RelativeSource prend.

Bien sûr, je mesure un petit exemple artificiel ici. La performance de l'approche ElementName peut varier en fonction du nombre d'éléments cités sont dans la portée. Et il peut y avoir d'autres facteurs imprévus qui pourraient produire des résultats complètement différents dans les scénarios réels. Je recommande donc d'effectuer des mesures similaires dans le cadre d'une application réelle si vous souhaitez obtenir une meilleure image.

Je répète l'expérience avec 10 TextBlocks au lieu de 1. ElementName puis moyennées 2020us alors que l'approche RelativeSource moyenne 2073us, encore une fois plus de 2000 itérations pour les deux tests. Bizarrement, il y a une petite différence ici, non seulement en termes relatifs, mais en termes absolus -. Les exemples d'un élément a montré une différence de 72us, où les exemples de dix d'éléments ont montré une différence de 53us

Je commence à penser que je provoque une plus grande variabilité en exécutant mes tests sur ma machine principale, au lieu d'un soigneusement configuré avec aussi peu des choses que possible pour minimiser le bruit.

Une plus grande variation: toujours avec 10 blocs de texte liés, j'ai ajouté dix plus vides, non liés, des blocs de texte nommés au contrôle de l'utilisateur. L'idée était de présenter les choses plus nommées - ElementName doit maintenant trouver un élément nommé dans les 11 choses nommées. La moyenne des ElementName est maintenant 2775us. L'approche RelativeSource avec ces 10 éléments supplémentaires nommés est sorti à 3041us.

Encore une fois, je suspecte la variabilité sur ma machine de bureau ici -. Il semble bizarre que RelativeSource a obtenu des résultats nettement pire ici que dans le scénario qui aurait dû être plus à l'avantage de ElementName

Quoi qu'il en soit, ce que fait semble raisonnablement clair que le coût de la charge ici est beaucoup plus sensible au nombre d'éléments qu'il est à quel style de liaison que vous utilisez. Il y a apparemment un petit avantage à ElementName mais assez petit (et avec des résultats assez étranges) pour suspicion en cause la validité de la conclusion qu'il est nécessairement plus rapide.

Nous pourrions construire des expériences plus prudentes pour obtenir une meilleure image. Mais à mon avis, si vous ne pouvez pas démontrer de manière concluante une différence significative des performances lors de l'exécution sur un ordinateur ordinaire, il est en fait une perte de temps discutiez qui est plus rapide.

En conclusion: la performance est la mauvaise chose à se concentrer sur luiré. Choisissez selon rend le code plus lisible.

Answer 2

La plus tardive des deux besoins à pied de l'arbre visuel à la recherche d'un type ancêtre particulier, où les regards avant directement au NameScope de la fenêtre pour un objet enregistré avec ce nom ... je pense serait le plus tard est légèrement plus lent ... cela dit, je ne pense pas qu'il y aura une différence significative de performance.

it helps,

Aj