ElementName vs RelativeResource?

Question

¿Cuál de los siguientes enlaces TextBlocks' cuesta más rendimiento:

<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>

Estoy seguro de que mi pregunta podría tomar diferentes cuando los TextBlocks están en un alto nivel de anidamiento tener muchos hermanos y padres.

Consideraciones

(basado en pensamientos personales únicamente, puede que me equivoque en cada uno en particular!):

• ElementName :

  • Podría buscar y comparar elemento actual a un mayor control, a través de todos sus hijos, hermanos, tíos y tíos abuelos incluyendo antepasados ??(tal vez hay una tabla hash de todos los nombres registrados?)
  • Obtener una propiedad de un control Name debe costar menos rendimiento que llamar GetType.
  • La comparación de una cadena es más barato que la comparación de tipos, sobre todo cuando se sabe que la mayoría de los controles no tienen ni siquiera su conjunto Name.

• FindAncestor :

  • sólo se iterar a través de los antepasados, no siblingls 'tíos', 'primos', etc.
  • La mayoría de los usos probables GetType para determinar el tipo ancestro; GetType cuesta más el rendimiento entonces un simple propiedad de captador Name (quizás AD son diferentes?)

Answer 1

Por lo general es una idea terrible para tratar de responder a este tipo de cosas con el argumento sobre el que cree que será más rápido. Es mucho mejor para construir un experimento para medir la misma.

He modificado la configuración de un poco - Pongo el Xaml relevante en un control de usuario, y con destino a la propiedad ya Name UserControl no tiene una propiedad Title. Entonces escribí algo de código para crear una nueva instancia del control y añadirlo a la interfaz de usuario, y se utiliza la Stopwatch para medir el tiempo necesario para construir y cargarlo. (Inicio el momento justo antes de la construcción del control de usuario y dejo justo después del control de usuario levanta su caso Loaded.)

ejecutar el código desde un DispatcherTimer 20 veces por segundo, así que puede tomar muchas medidas con la esperanza de reducir el error experimental. Para reducir al mínimo las distorsiones debidas a la depuración y el código de diagnóstico, estoy corriendo en una versión de lanzamiento, y sólo calcular e imprimir el promedio después de 2000 iteraciones han completado.

Después de 2000 iteraciones, el enfoque ElementName promedios 887us.

Después de 2000 iteraciones, el enfoque RelativeSource promedios 959us.

Así ElementName es, en este experimento particular, un poco más rápido que RelativeSource. Carga de un UserControl trivial con sólo un Grid y uno TextBlock donde sólo hay un elemento llamado, las miradas de aproximación ElementName a tomar el 92% del tiempo de carga que lleva el enfoque RelativeSource.

Por supuesto, estoy midiendo un pequeño ejemplo, aquí artificial. El rendimiento del enfoque ElementName podría variar en función de la cantidad de elementos con nombre son en su alcance. Y puede haber otros factores imprevistos que podrían producir resultados completamente diferentes en escenarios reales. Por lo que recomiendo realizar mediciones similares en el contexto de una aplicación real, si desea obtener una mejor imagen.

I repitió el experimento con 10 TextBlocks en lugar de 1. ElementName 2020us entonces promediados mientras que el enfoque RelativeSource promedió 2073us, de nuevo más de 2000 iteraciones para ambas pruebas. Extrañamente, hay una diferencia más pequeña aquí, no sólo en términos relativos, pero en términos absolutos -. Los ejemplos de un elemento mostraron una diferencia de 72us, donde los ejemplos de diez elementos mostraron una diferencia de 53us

Estoy empezando a sospechar que estoy haciendo más variabilidad mediante la ejecución de mis pruebas en mi máquina principal, en lugar de uno cuidadosamente configurado con tan poco material como sea posible para minimizar el ruido.

Una variación más: aún con 10 bloques de texto enlazados, he añadido diez,, bloques de texto no unidas nombrados más vacías para el control de usuario. La idea era introducir cosas más nombrado - ElementName ahora tiene que localizar un elemento denominado plazo de 11 cosas nombradas. El promedio para ElementName es ahora 2775us. El enfoque RelativeSource con estos 10 elementos extra con nombre salió en 3041us.

Una vez más, la variabilidad sospechoso en mi máquina de escritorio aquí -. Me parece raro que RelativeSource ha realizado significativamente peor aquí que en el escenario que debería haber sido más ventajoso para ElementName

De todos modos, lo que hace parece razonablemente claro es que el costo de la carga aquí es mucho más sensible a la cantidad de elementos de lo que es el estilo de encuadernación que utilice. Aparentemente, hay una pequeña ventaja a ElementName pero lo suficientemente pequeño (y con suficientes resultados extraños) para echar sospechas sobre la validez de la conclusión de que es necesariamente más rápido.

Así que podríamos construir experimentos más cuidado para obtener una mejor imagen. Pero en mi opinión, si no se puede demostrar de manera concluyente una diferencia significativa en el rendimiento cuando se ejecuta en una computadora ordinaria, entonces es básicamente una pérdida de tiempo discutir sobre los cuales es más rápido.

Así que en conclusión: el rendimiento es el mal que hay que centrarse en élre. Recoger lo que hace que el código sea más legible.

Answer 2

La última de las dos necesidades a recorrer el árbol visual en busca de un tipo de ancestro en particular, en tanto que las miradas anteriores directamente a NameScope de la ventana de un objeto registrado con ese nombre ... creo que ha de ser este último es marginalmente más lenta ... dicho esto, no creo que habrá una diferencia significativa del rendimiento.

Espero que ayuda,

Aj