WPF C# Application Performance

Question

Tenemos una aplicación C# WPF escrita en .NET 4.0, que tiene un enlace de datos relativamente simple y funcionalidad de red.

El diseño implica algunos "ajustes", incluidos algunos colores de vuelo estacionario, etc.

En 3 máquinas, de una implementación que cubre 20, estamos experimentando algunos problemas de rendimiento muy extraños con la interfaz de usuario.

Efectivamente, después de un reinicio, la aplicación funciona bien, pero después de un cierto tiempo (indeterminado), la interfaz de usuario se vuelve increíblemente lenta. Por ejemplo, colocando el mouse sobre un botón, y habrá un retraso de hasta un par de segundos antes de que se aplique/renderice el estilo de color.

Las máquinas tienen especificaciones casi idénticas. Los controladores de gráficos se han actualizado y la configuración estándar es de dos tarjetas NVidia Quadro 290. Complementariamente, hicimos una aplicación de "prueba" que contenía SOLAMENTE algunos componentes de UI de prueba (incluida la cinta Fluent Ribbon) y ningún código detrás. El problema aún ocurre

He ejecutado el Windows Performance Suite para 'profundizar' en el WPF en tiempo de ejecución, y, curiosamente, la UI vuelve a la capacidad de respuesta normal si la opción 'Desactivar compatibilidad con regiones sucias' está marcada. Mi comprensión es que, en todo caso, ¡esto debería disminuir el rendimiento aún más!

No tengo nada más que probar aquí. Un análisis de rendimiento de DotTrace sugiere que la mayor parte del tiempo de la aplicación se gasta en PresentationFramework.dll.

[EDITAR] Todas las máquinas son Windows XP SP3.

[EDIT] Es posible que esto ocurra en todas las máquinas y que la aplicación no se pueda ejecutar durante el tiempo suficiente como para presentar el problema. Estamos probando esto ahora.

[EDIT] Debo señalar también que estamos experimentando con la revisión detallada here. Se ha instalado en una sola máquina por el momento, y actualizaré en consecuencia.

[EDITAR - 24 horas después] Por lo tanto, dos máquinas han estado utilizando el mismo código durante la noche. En mi máquina (que nunca ha demostrado el problema), después del inicio de sesión inicial la aplicación era muy lenta, pero después de menos de un minuto volvía a la normalidad. (Lo puse en la máquina claramente sacando cosas de la HDD). En la otra máquina (que generalmente demuestra el problema), la aplicación mejoró después de algunos segundos, pero todavía es lenta en comparación con la mía.

[EDIT - 48 horas más tarde] En la máquina de prueba, la aplicación de prueba es ahora totalmente insensible (bloqueado) después de correr durante 48 horas. En la misma máquina, una aplicación WPF 'shell' liviana (que contiene un control de pestañas, algunos botones y algunos paneles y rejillas) sigue funcionando y responde perfectamente. Entonces, algo en estos controles más complejos está causando este problema ... lo que de hecho apunta a desencadenantes (potencialmente) y delega que podría ser la causa raíz. Buscaré un perfil de la aplicación/controles nuevamente. Mientras tanto, ¿alguien tiene algún consejo sobre cómo asegurarse de que la aplicación se "limpia" después de sí misma a intervalos regulares? ¡Porque estamos viendo controles de terceros aquí, así que mis opciones para editarlos son limitadas!

¡Agradecería cualquier consejo que pueda proporcionarse!

Answer 1

intenta reproducir wpf en modo de software.

en el evento Loaded:

HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource; 
HwndTarget hwndTarget = hwndSource.CompositionTarget; 
hwndTarget.RenderMode = RenderMode.SoftwareOnly; 

Answer 2

Algo a tener en cuenta al comparar el rendimiento entre las máquinas de usuarios y desarrolladores es el tiempo que tarda en cargar los ensamblados de WPF.

En una máquina de desarrollo, es posible que ya tenga visual studio ejecutándose o que haya ejecutado anteriormente otras aplicaciones WPF y que todos los ensamblajes se hayan cargado antes de ejecutar la aplicación.

En una máquina de usuario, tal vez recién reiniciado, los ensamblajes se cargarán cuando la aplicación se inicie, lo que hará que el arranque sea mucho más lento. Dependiendo de cómo esté configurada la aplicación, pueden cargarse ensamblajes adicionales cuando se usan varias características/páginas por primera vez.

He encontrado que el EQUATEC profiler es útil en la depuración de estos problemas de rendimiento. Al cambiar el perfil a "Información completa habitual" en las opciones de la aplicación antes de crear su proyecto, el perfil se reducirá al nivel de enlace.