studio - ¿Qué características debería tener un perfilador C#/. NET?

dottrace (14)

Esto podría ser un anuncio fronterizo, sin mencionar subjetivo, pero la pregunta es honesta. Durante los últimos dos meses, he estado desarrollando un nuevo generador de perfiles de fuente abierta para .NET llamado SlimTune Profiler ( http://code.google.com/p/slimtune/ ).

Es un esfuerzo relativamente nuevo, pero cuando miré la gama de perfiladores disponibles, no quedé terriblemente impresionado. He hecho un trabajo inicial basado en productos existentes, pero sentí que este sería un buen lugar para preguntar: ¿qué es exactamente lo que QUIERES de un generador de perfiles?

Vengo de gráficos y juegos en tiempo real, por lo que es importante para mí que un generador de perfiles sea lo más rápido posible. De lo contrario, el juego se vuelve injugable y perfilar un juego lento no reproducible tiende a no ser muy esclarecedor. Estoy dispuesto a sacrificar algo de precisión como resultado. Ni siquiera me importan las excepciones. Pero no estoy muy familiarizado con lo que les interesa a los desarrolladores para otros tipos de aplicaciones. ¿Hay alguna característica de make or break para usted? ¿Dónde caen las herramientas existentes?

Una vez más, me disculpo si esto está fuera de lugar para StackOverflow, pero siempre ha sido un recurso increíblemente útil para mí y hay una gran variedad de desarrolladores aquí.

Descargue la versión de Team Suite de Visual Studio 2010 Beta 1 (gratis durante 6 meses más o menos?) Y perfile una aplicación C #.

Créeme. :)

Editar: el modo Línea por línea me ayudó a aislar a un operador que causaba un problema de rendimiento. Pude haberlo encontrado sin resaltar por línea, pero cuando puedes desplazarte y ver las líneas calientes usándolo, puedes arreglarlo tan fácilmente.

Ah, y si quieres comentarios / ayuda, contáctame por separado.

Vista de resumen: seleccione cualquier sección de la gráfica de la CPU para filtrar.
Vista de resumen http://www.280z28.org/images/vsx/ProfilingSummarySmall.png

Me encanta la línea por línea en el margen:
Vista de detalles http://www.280z28.org/images/vsx/ProfilingDetailsSmall.png

Hace años, construí un generador de perfiles y lo describí en SO, en respuesta a otra pregunta que no puedo encontrar en este momento, sobre cómo crear un generador de perfiles.

Se basa en automatizar, al menos parcialmente, la técnica que he usado durante décadas, de la cual se da un ejemplo here . Se basa en el muestreo de pila, y la clave está en cómo se presenta esa información y en el proceso de pensamiento por el que pasa el usuario.

Las creencias generales sobre el ajuste del rendimiento, que se enseñan en la escuela (por profesores con poca exposición al software del mundo real) y que continúan a través del fenómeno de 50,000 programadores no pueden ser incorrectos, sugiero que deben ser cuestionadas y puestas en práctica. un pie más firme. Estoy muy lejos de sentirme solo de esta manera, como podría deducir de navegar alrededor de SO.

Creo que la tecnología de perfiladores está evolucionando gradualmente (para mejor, en mi opinión) hacia el muestreo de la pila y las formas de explorar los resultados. Aquí están las ideas de las que dependo (que puede encontrar un poco discordante):

Descubrir problemas de rendimiento para que puedan ser reparados y medir el rendimiento son dos tareas completamente diferentes. Son medios y fines, y no deben confundirse.
Para descubrir problemas de rendimiento, lo que se necesita es encontrar qué actividades representan una gran cantidad de tiempo de reloj de pared que se está gastando y que se puede reemplazar con algo más rápido.
Lo bueno de estas actividades es que el hecho de que toman tiempo las expone a muestras del estado del programa en tiempo aleatorio.
No se necesitan muchas muestras, si se toman durante el intervalo que le interesa. Es decir, no tiene sentido tomar muestras mientras espera la entrada del usuario. Para ello, en mi perfil, dejo que el usuario active las muestras con las teclas.
La razón por la que no necesitas muchas muestras es esta. Cualquier problema de rendimiento dado cuesta una fracción X del tiempo del reloj de pared en el intervalo de interés. Una muestra aleatoria en ese intervalo tiene una probabilidad X de "atraparla en el acto", por lo que si se toman N muestras, el número esperado de muestras que lo capturan en el acto es NX. La desviación estándar de ese número de muestras es sqrt (NX (1-X)). Ejemplo, si N = 20 y X = 20%, puede esperar aproximadamente de 2 a 6 muestras para mostrar el problema. Eso le da una medida imprecisa del problema, pero le dice que vale la pena corregirlo, y le da una ubicación muy precisa, sin ningún otro trabajo de detective.
Los problemas suelen manifestarse como más funciones, procedimientos o llamadas a los métodos que los necesarios, especialmente a medida que el software crece, con más capas de abstracción y, por lo tanto, más capas de apilamiento. Lo primero que busco es llamar a sitios (no funciones, sino declaraciones de llamadas o instrucciones) que aparecen en varias muestras de pila. Cuantas más muestras de pila aparecen, más cuestan. Lo segundo que busco es "¿podrían ser reemplazados?" Si no pueden ser reemplazados por algo más rápido, simplemente son necesarios y debo buscar en otro lado. Pero a menudo pueden ser reemplazados, y obtengo una buena aceleración. Así que estoy mirando cuidadosamente las muestras de la pila en particular, sin agregarlas en las mediciones.
La recursividad no es un problema porque el principio de que el costo de una instrucción es el porcentaje de tiempo que está en la pila es el mismo, incluso si se llama a sí mismo.
Esto no es algo que hago una vez, sino en pases sucesivos. Cada problema que soluciono hace que el programa tome menos tiempo. Eso significa que otros problemas se vuelven fracciones más grandes del tiempo, haciéndolos más fáciles de encontrar. Este efecto se combina, de modo que a menudo son posibles mejoras dramáticas en el rendimiento acumulativo.

Podría continuar, pero le deseo suerte, porque creo que hay una necesidad de mejores herramientas de creación de perfiles, y usted tiene una buena oportunidad.

Hay EQATEC Profiler que es un generador de perfiles .Net gratuito que he querido usar.

Una cosa que me gustaría ver es compatibilidad Mono. ¡He comenzado a incursionar en Mono, y sería genial tener un perfilador .Net y Mono!

Lo que me gustaría en un generador de perfiles:

Debería funcionar en 32 y 64 bits
Debería tener componentes para todos los niveles (cliente, servidor de aplicaciones, base de datos) y alguna forma de correlacionarlos. Por ejemplo, sería bueno ver cómo los cambios realizados en cualquiera de los niveles afectan a otros niveles. Eso podría ayudar a decidir en qué nivel implementar características específicas.
Interfaz de línea de comandos para usar con escenarios automatizados (servidor de compilación, pruebas de estrés, etc.)
Debe tener un modo de muestreo ligero y un modo instrumentado más preciso. El segundo impacto en las medidas de ejecución es lo menos posible.
Una GUI para facilitar el uso y que debería generar los archivos de configuración necesarios para usar el modo de línea em comand line
Genere resultados en un formato estándar (si tal cosa existe) para que pueda consumir los resultados con otras herramientas
También debería generar o exportar resultados al formato de Visual Studio (* .vsp)
Compare dos o más archivos de resultados para ver la evolución o regresión de la base de códigos.
Reúna y correlacione los datos de la aplicación de destino con los datos de PerfMon de otros procesos que se ejecutan en cada máquina de destino para identificar el uso simultáneo de recursos (memoria, procesador, disco y red de E / S)
Determine los umbrales para los cuales se debe invocar algún mecanismo de alerta. Un ejemplo de esto sería enviar un correo electrónico a alguien si un escenario específico toma más tiempo de lo especificado.
Habilidad para adjuntar y desconectar de un proceso en ejecución para recopilar datos de muestreo sin interferir con la aplicación de destino. Debe tener para usar en sitios de producción.

Me gustaría al menos algo de compatibilidad con ASP.NET, aunque entiendo que en realidad es bastante difícil hacerlo funcionar.

Línea por línea es tan agradable en Shark que también me gustaría tenerlo en .NET.

Una opción de visualizadores es algo bueno: me gustaría ver un conjunto de diferentes árboles de llamadas, gráficos estadísticos e incluso un mapa de calor de los métodos más frecuentes.

Mi lista de deseos:

Realmente fácil de usar: GUI simple (pero potente)
Rendimiento espectacular : capacidad para crear perfiles de aplicaciones que están bajo un uso extremadamente intenso.
Soporte X64 y X32
Entiende SQL , es capaz de darme rastros de pila y duración de todas mis llamadas SQL, junto con SQL.
Fácil de perfilar, sin necesidad de pasar por un complejo, recompile el proceso de la aplicación.
Servicios, sitios web y procesos fáciles de perfilar que se inician como efectos secundarios
Un "modo de producción" que le permite reunir estadísticas clave de un sistema basado en la producción.
- "Buscador automático de cuello de botella": se ejecuta contra una aplicación de producción y el uso de la heurística determina qué métodos son lentos.
Por análisis de hilos, dime qué hilos están haciendo todo el trabajo y dónde.
Perfil en varias granularidades, permite realizar un perfil "barato" que solo recopila información clave y profundiza con perfiles granulares.
Rastreador de excepciones, permítame seguir todas las excepciones que se lanzan en mi aplicación (estadísticas clave e información detallada)
Por perfiles de subprocesos: me permite crear un perfil de un solo subproceso en una aplicación

Mi perfil preferido fue "DevPartner Performance Analysis Community Edition" ( http://researchlibrary.theserverside.net/detail/RES/1165507815_474.html?psrc=MPR ), desafortunadamente ya no está disponible.

Lo que lo hizo destacar contra la competencia fue el análisis gráfico que mostró un cuadro para el método seleccionado actual y conectores salientes a los métodos llamados que muestran el porcentaje de tiempo invertido en cada uno. También conectores a llamadas entrantes. Por supuesto, los métodos calling y call tenían el mismo y podías expandirlos según fuera necesario. De esta forma, podías navegar libremente a lo largo de la pila de llamadas, ver la pila lo más profundo que quisieras y abordar el camino caliente en tu fragmento.

La segunda demanda sería "facilidad de uso", es decir, debería funcionar con todos los tipos de aplicaciones relevantes, Windows exe, aplicación web, servicio de Windows, servicio WCF, (¿Silverlight?), .... Y no solo con pequeñas aplicaciones de muestra, sino también con aplicaciones no tan triviales de tamaño empresarial.

Mis requisitos:

Recopile estadísticas sin impacto para la aplicación, por ejemplo, no llene la memoria, permita que se recopilen datos de las aplicaciones en cuestión
Posibilidad de especificar medidas de forma simple y repetible (basada en datos)
Automatizable para que pueda repetir mediciones sin apuntar y hacer clic, y sin IU
Permitirnos entender problemas relacionados con WPF y otras tecnologías declarativas como DLR o WF
Sin instalación, sin gac, msi, etc., incluso mejor si se puede ejecutar a través de una red
Soporte 64 bit desde el principio
No intente conocer todo el análisis que podría hacerse: fomentar un ecosistema. Si las estadísticas en bruto se pueden analizar usando otras herramientas mucho mejor.
UI si alguno debería ser bueno, pero son las estadísticas que importan. Así que no dedique tiempo a eso, obtenga buenos perfiles para el núcleo.
- Soporte de perfiles de aplicaciones que no son simples exe como servicios y aplicaciones web simplemente.

Me gustaría:

Considere la compatibilidad con aplicaciones cruzadas: las aplicaciones grandes a menudo necesitan comprender el comportamiento de rendimiento de las aplicaciones en muchos ejecutables. Si su generador de perfiles permite una fácil correlación de estos datos, entonces tanto mejor

Phsr ya mencionó el EQATEC Profiler .

Una característica que tiene que me gusta es que, incluso sin leer ninguna documentación o prestar atención a lo que estoy haciendo, pude, con éxito, de principio a fin, perfilar una aplicación. La usabilidad es algo maravilloso. Tenga cuidado con la forma en que agrega todas esas opciones sofisticadas ... no mate la usabilidad en el proceso.

Sería bueno si las medidas de perfilado .NET relacionadas de Perfmon están integradas, para evitar el monitoreo "doble" con perfmon y su aplicación. Esto es especialmente útil para todos los artículos relacionados con la memoria.

Si hiciera las mismas cosas que JetBrains dotTrace , estaría muy contento de hecho.

Un par de cosas que realmente me encantaría ver:

Recopilación de datos:

Una opción para permitir el seguimiento del contexto a través de un nuevo hilo. Es decir, cuando ocurre una llamada al nuevo Thread () o ThreadPool.Queue ... (), cuente el trabajo realizado por el otro hilo como si ocurriera dentro de la función de llamada, aunque ocurra en diferentes hilos, y el el método de llamada no es en realidad el bloqueo. Esto finalmente permitiría identificar código que produce mucho trabajo en un método común que implementa un patrón asíncrono. ¡Esto realmente podría ser genial!
Seguimiento de asignaciones dentro de métodos. Existe la posibilidad de que el generador de perfiles .Net ya lo haga, pero identificar qué métodos realizan muchas asignaciones podría ser invaluable. Incluso si otras herramientas pueden hacer esto, tener todo en una herramienta siempre es genial.
Una agregación capaz de detectar "picos" en el uso y analizar solo ellos. Esto podría ser útil al analizar un proceso en segundo plano que se comporta de forma inesperada y con poca frecuencia.

UI final:

La capacidad de comparar dos carreras y resaltar las principales diferencias entre ellas.
La navegación de Árbol de Llamadas y la expansión de caminos calientes (estilo VS) también sería genial.

Una de las cosas que veo mal en casi todos los perfiles es una API administrada para realizar perfiles automatizados y pruebas automatizadas.

Me imagino que piensas, WTF ... ¿por qué le gustaría automatizar el perfil?

La respuesta es que algunos de nuestros clientes tienen requisitos con respecto a la velocidad, el uso de mem, etc. Por lo tanto, para cada nueva versión nos gusta realizar una prueba sobre las cosas mencionadas antes de enviarlas.

Agregaré uno más aquí que sería realmente dulce. Haga un ensamblaje simple que tenga una función Mark(string) disponible, donde si la aplicación llamó a ese método, entonces en los resultados puede seleccionar ver los resultados solo desde allí hasta (el final | alguna otra marca especificada). Otra posibilidad es BeginSequence y EndSequence o algo así. Doble más si puede especificar si la marca se aplica solo al hilo actual o a todos los hilos.