Creación de perfiles de un complemento dll

Question

Quiero crear un perfil de un complemento dll en C++. Tengo acceso a la fuente (siendo el autor/mantainer) y puedo modificarlos (si es necesario para la instrumentación). Lo que no tengo es la fuente/símbolos/etc. del programa host que llama al dll. Solo tengo los encabezados necesarios para compilar el complemento. El dll se invoca a la acción del cliente.

¿Cuál es la mejor manera de proceder para crear un perfil del código? No es realista "envolver" un ejecutable alrededor de la dll y no sería útil porque dado que en el complemento estoy llamando a algunas funciones desde el host Y necesito crear un perfil de esas rutas, un contenedor podría sesgar el rendimiento.

Edición después comentario Kieren Johnston: Tu lugar ideal para enganchar en el DLL cargado al igual que el depurador es capaz de (adhiriéndose al proceso host que ejecuta y la colocación de un punto de interrupción en algún lugar de la DLL, según sea necesario). ¿Es posible? Si no es así, voy a tener que hacer otra pregunta para preguntar por qué :-)

Estoy utilizando la edición de TFS de Visual Studio 2010.

Los puntos de bonificación para proporcionar sugerencias/respuestas para la misma tarea bajo AIX (ah , las alegrías de múltiples ambientes!).

Answer 1

Esto es posible aunque un poco molesto.

1. Despliegue su plug-in DLL para los que la aplicación host necesita que sea
2. poner en marcha su programa de control y compruebe que está utilizando el plug-in
3. crear una nueva sesión Rendimiento
4. Agregar el anfitrión EXE como un objetivo en la sesión de la etapa 3
5. Seleccionar muestreo o Instrumentación para su sesión
6. Lanzamiento de la sesión de perfil

Durante todo esto, mantenga su solución de complemento cargada y VS debería encontrar automáticamente los símbolos para su complemento.

Answer 2

No estoy seguro acerca de VS10, pero en las versiones anteriores, depura la dll especificando el exe para ejecutarlo.

Vamos a dividir el problema en dos partes: 1) ubicar lo que podría llamar "cuellos de botella", y 2) medir la aceleración general que obtiene al arreglar cada una.

(2) es fácil, ¿no? Todo lo que necesitas es un temporizador externo.

Eso deja (1). Si eres como la mayoría de las personas, piensas que encontrar los "cuellos de botella" no se puede hacer sin algún tipo de sincronización precisa de las partes del programa. No es así, porque la mayoría de las veces las cosas que necesita corregir para obtener la mayor velocidad no son cosas que pueda detectar de esa manera. No son necesariamente malos algoritmos, o funciones lentas, o puntos de acceso. Se distribuyen cosas que se hacen con un código perfectamente diseñado y de apariencia inocente, que simplemente presenta una gran oportunidad de aceleración si se codifica de una manera diferente.

Here's an example donde un programa razonablemente bien escrito había su tiempo de ejecución reducido de 48 segundos a 20, 17, 13, 10, 7, 4, 2,1, y, finalmente, 1,1, más de 8 iteraciones. ** Eso es un factor de compuesto speedup de más de 40x. El factor de aceleración que puede obtener es diferente en cada programa diferente: algunos pueden obtener menos, algunos pueden obtener más, dependiendo de qué tan cerca estén de lo óptimo en primer lugar. No hay misterio de cómo hacer esto. El método era random pausing. (Es una alternativa al uso de un generador de perfiles. Los perfiladores miden varias cosas y le dan varias pistas que pueden o no ser útiles, pero no le dicen confiablemente cuál es el problema)

** The speedup los factores logrados, por iteración, fueron 2.38, 1.18, 1.31, 1.30, 1.43, 1.75, 1.90, 1.91. Otra forma de expresarlo es el porcentaje de tiempo reducido en cada iteración: 58%, 15%, 24%, 23%, 30%, 43%, 48%, 48%. Los fanáticos del perfilador me cuestan mucho porque el método es muy manual, pero nunca hablan de los resultados de la aceleración. (Quizás eso cambie.)