¿Qué características debe tener un analizador C# /. NET?

Question

Esto podría ser un anuncio límite, 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í.

Answer 1

Mis requisitos:

• Estadísticas Almacenamiento sin impacto de la aplicación - por ejemplo, no llenar la memoria, permiten que los datos que deben recogerse lejos de aplicaciones en la pregunta
• capacidad de especificar las mediciones de forma sencilla y repetible (impulsada por los datos)
• Automatizable para que pueda repetir las mediciones sin apuntar y hacer clic, y sin interfaz de usuario
• nos permiten comprender los problemas relacionados con el WPF y otras tecnologías declarativas como DLR o WF
• ninguna instalación - sin GAC, msi etc, aún mejor si se puede ejecutar en una red
• Soporte 64 bits desde un principio
• No intente saber 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 debe ser bueno, pero son las estadísticas las 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.

haría gusta:

• considerar el apoyo aplicación cruz - grandes aplicaciones a menudo necesitan para entender el comportamiento de rendimiento a través de muchas aplicaciones ejecutables. Si el generador de perfiles permite una fácil correlación de estos datos a continuación, tanto mejor

Answer 2

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

Answer 3

Hay EQATEC Profiler que es un generador de perfiles .Net libre que he tenido la intención de utilizar.

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

Answer 4

Mi lista de deseos:

• Muy fácil de usar - interfaz gráfica de usuario sencilla (pero potente)
• rendimiento espectacular - capacidad de describir aplicaciones que están en condiciones de uso muy pesado.
• X64 X32 y apoyo
• Comprende SQL, es capaz de dar mi trazas de la pila y la duración para todas mis llamadas SQL, junto con SQL.
• Fácil de perfil, sin necesidad de pasar por un complejo, recompile el proceso de la aplicación.
• Fácil de perfil servicios, sitios web y los procesos que se lanzan como efectos secundarios
• Un "modo de producción", que le permite recopilar estadísticas clave de un sistema basado en la producción.
  • "Buscador automático de cuello de botella": ejecutarlo en una aplicación de producción y usar heurística determinar qué métodos son lentos.
• por análisis de hilo, dime cuales hilos están haciendo todo el trabajo y dónde.
• Perfil en varias granularidades, permiten realizar un perfil "barato" que solo recopila información clave y profundiza con perfiles granulares.
• Excepción tracker, me permite realizar el seguimiento de todas las excepciones que son arrojados en mi aplicación (estadísticas clave e información detallada)
• Por perfiles de rosca - permítanme perfil de un solo hilo en una aplicación

Answer 5

Descargar la versión de Team Suite de Visual Studio 2010 Beta 1 (gratis durante 6 meses más o menos?), y el perfil de una aplicación C#.

Confíe en mí. :)

Editar: El modo línea por línea me ayudó a aislar 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 quiere comentarios/ayuda, contácteme por separado.

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

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

Answer 6

Voy a añadir una 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, luego 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.

Answer 7

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

Answer 8

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

Lo que hizo que se destacara contra la competencia fue el análisis gráfico que mostró una caja 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 manera, podías navegar libremente a lo largo de tu 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.

Answer 9

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 una buena cosa. Me gustaría ver un montón de diferentes árboles de llamadas, gráficos estadísticos e incluso un mapa de calor de los métodos que se llaman con más frecuencia.

Answer 10

Lo que me gustaría en un perfilador:

• deben trabajar en 32 y 64 bits
• En caso de tener Componentes para todos los niveles (cliente, servidor de aplicaciones, bases de datos) y de alguna manera de correlacionar entre ellos. 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 tensión, 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 interfaz gráfica de usuario para facilitar su uso y que debe generar los archivos de configuración necesarios para utilizar el modo de línea em COMAND
• generar resultados en un formato starndard (si existe tal cosa) por lo que pueden consumir los resultados con otras herramientas
• También debería generar o exportar resultados al formato de Visual Studio (* .vsp)
• Compara entre dos o más archivos de resultados, para ver la evolución o regresión del código base.
• Recoger y correlacionar los datos de la aplicación de destino con los datos de Monitor de rendimiento de otros procesos que se ejecutan en cada máquina de destino para identificar el uso de recursos concurrente (memoria, procesador, disco y red I/O)
• determinar los umbrales para los que algún mecanismo de alerta debe ser invocado. 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.
• Posibilidad de 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.

Answer 11

Un par de cosas que realmente me gusta ver:

Data Collection:

• una opción para permitir el seguimiento del contexto a través del nuevo hilo. Es decir, cuando una llamada a cualquiera de nuevo Thread() o ThreadPool.Queue ...() pasa, cuenta el trabajo realizado por el otro hilo como si sucede dentro de la función de llamada, a pesar de que se producen 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!
• asignaciones de seguimiento 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 el análisis sólo a ellos. Esto podría ser útil al analizar un proceso en segundo plano que se comporta de forma inesperada y con poca frecuencia.

final de interfaz de usuario:

• La capacidad de comparar dos carreras, y poner de relieve las principales diferencias entre ellos.
• de navegación de llamadas en árbol y la expansión de la ruta caliente (VS-estilo) sería genial también.

Answer 12

Phsr ya mencionó el EQATEC Profiler.

Una de las características que tiene que me gusta es que, incluso sin necesidad de leer cualquier documentación o prestar ninguna atención en absoluto a lo que estoy haciendo, yo era capaz de éxito, de principio a fin, el perfil de 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. Hace

Answer 13

años he construido un generador de perfiles, y lo describió en Así que en respuesta a otra pregunta que no puedo localizar en este momento, acerca de cómo construir un generador de perfiles.

Se basa al menos en la automatización parcial de la técnica que he usado durante décadas, de las cuales se da un ejemplo de 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 cuestionado y puesto en una base 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 perfiles está evolucionando gradualmente (para mejor en mi opinión) hacia la pila-muestreo y formas de explorar los resultados. Éstos son los puntos de vista que dependo (que es posible encontrar un poco discordante):

• El descubrimiento de los problemas de rendimiento para que puedan ser fijos, y medir el rendimiento, son dos tareas totalmente diferentes. Son medios y fines, y no deben confundirse.

• Para descubrir problemas de rendimiento, lo que se necesita es encontrar las actividades que representan grandes cantidades de tiempo de reloj de pared que se gastan y que pueden reemplazarse 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 necesita 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 de los necesarios, especialmente a medida que el software crece, con más capas de abstracción y, por lo tanto, más capas de capas. 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 seguir, pero le deseo suerte, porque creo que hay una necesidad de mejores herramientas de perfilado, y usted tiene una buena oportunidad.

Answer 14

Una de las cosas que error en casi todos los perfiles es una API administrada para realizar perfiles automáticos y pruebas automáticas.

Me imagino que piensas, WTF ... ¿por qué querría uno automatizar el perfilado?

La respuesta es que algunos de nuestros clientes tienen requisitos con respecto a la velocidad, el uso de memoria, etc. Por lo tanto, para cada nuevo lanzamiento nos gusta realizar una prueba sobre el material mencionado antes de enviarlo.