Solucione el problema de rendimiento con la aplicación WPF

Question

He hecho una lista de todo lo que puede ayudar a mejorar el rendimiento en una aplicación muy compleja con muchos controles. Si quieres agregar el tuyo, ¡bienvenido!

• Si conoce el tamaño del control, retire el auto e introduzca el valor real, por lo que el padre no tiene que analizar todas niño para comprobar el tamaño que necesita
• establecer el parámetro IsHitTestVisible = False si el elemento no tiene que ser interactivo
• Freeze todo objeto que se puede
• utilizar los recursos estáticos en lugar de recursos dinámicos
• no utilice el objeto Elipse, transformar la elipse a un camino
• Don uso Cuadro de texto o etiqueta si se puede utilizar un TextBlock
• Aplicar textura en lugar de la red cuando sea posible
• Sin FlowDocument
• Virtualize !! VirtualizingStackPanel en lugar de StackPanel
• No utilizar la lista, ObservableCollection es mucho más rápido
• utilizar la biblioteca de Dibujo, que es más rápido que la biblioteca Formas
• Compruebe su unión! Si un enlace no funciona, puede ser muy lento
• No utilice Visibility.Hidden, utilice Visibility.Collapsed cuando pueda
• DependencyProperty es 3 veces más rápido que INotifyPropertyChanged
• StreamGeometry es más rápido que PathGeometry
• ¡Borre los controladores de eventos cuando haya terminado con ellos!
• No utilice la propiedad opacidad del objeto, si es posible, usar su opacidad del color
• Compruebe si su aplicación es la representación de hardware (nivel 2)
• Reducir el tamaño/calidad de la imagen cuando se puede
• ¡La imagen de representación es mucho más rápida que el renderizado vectorial!

herramientas que utilizo:

• WPF Inspector
• Snoop
• conjunto WPFPerf
• Visual Studio perfilador
• CLR Profiler para .NET

Answer 1

Esto es realmente un comentario y no un respuesta pero no espacio suficiente para el resto.

ObservableCollection mucho más rápido que List me pareció intuitivo ya que ObservableCollection implementa iList.

Tengo una lista de 660,000 palabras que probé en un ListView (virtualización). Creó los tipos de colección a continuación y creó botones para cambiar el enlace del código. Todas las colecciones rendidas instantáneamente (el poder de la virtualización).

La variable es el momento de crear la colección y las características que necesita de la colección. Se utilizó SQLdataReader para completar la colección. Hay variabilidad en el SQLdataReader. Ran cada 10 veces obtuve resultados repetibles a 2 dígitos significativos e informo el promedio de 3 dígitos significativos. List beat ObservableCollection por aproximadamente 400 milisegundos. No midió la memoria, pero List claramente va a usar menos memoria.

Millisegundos para cargar 660,000 cadenas con un promedio de 40 caracteres cada una.

1510 List 
    1780 Dictionary 
    1820 HashSet 
    1980 ObservableCollection 
    8000 SortedDictionary 

En una colección muy grande, HashSet sería mucho mejor que List. HashSet debería vencer al diccionario; esos números están dentro de la variabilidad de esta prueba no rigurosa limitada.

Todo se reduce a las características. ObservableCollection admite inserción y eliminación dinámicas. Si necesita insertar y eliminar dinámicamente, es la mejor opción. Si no necesita insertar y eliminar dinámicamente, mi experiencia es que List es una mejor opción (a través de iNotifyPropertyChanged de ListItem List admite revisión dinámica).

La lista conserva el orden en que se agregan los elementos. HashSet no conserva el orden. Muchos factores para seleccionar qué colección usar. http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx

Tuve un comentario sobre el tiempo de acceso a un solo elemento. Accedí a los elementos [1], [100000], [200000], [300000], [400000], [500000], [600000] usando List, ObservableCollection y Dictionary. Eran todos 12 ms. El tiempo de acceso era un punto muerto y repetible.