2008-09-11 17 views
7

Espero que no todos estén usando Rational Purify.¿Cómo perfilas tu código?

Entonces, ¿qué hacer cuando se quiere medir:

  • tiempo tomado por una función
  • uso de memoria pico
  • cobertura de código

Por el momento, lo hacemos manualmente [utilizando las instrucciones de registro con marcas de tiempo y otra secuencia de comandos para analizar el registro y la salida a Excel. phew ...)

¿Qué recomendarías? Apuntar a herramientas o cualquier técnica sería apreciada!

EDIT: Lo siento, no especificó el medio ambiente en primer lugar, su llano C en una plataforma propietaria móvil

Respuesta

3

Probablemente desee herramientas diferentes para perfilar el rendimiento y la cobertura del código.

Para perfilar prefiero Shark en MacOSX. Es gratis de Apple y muy bueno. Si su aplicación es vainilla C, debería poder usarla, si puede obtener una Mac.

Para crear perfiles en Windows, puede utilizar LTProf. Barato, pero no excelente: http://successfulsoftware.net/2007/12/18/optimising-your-application/

(Creo que Microsoft realmente se está tirando a sí mismo en el pie al no proporcionar un perfil decente con las versiones más baratas de Visual Studio.)

Para la cobertura prefiero el Validator de cobertura en Windows: http://successfulsoftware.net/2008/03/10/coverage-validator/ Actualiza la cobertura en tiempo real.

1

nProf - Libre, hace que para .NET.

Hace el trabajo, al menos lo suficiente para ver el 80/20. (20% del código, tomando el 80% del tiempo)

0

Windows (.NET y Native Exes): AQTime es una gran herramienta para el dinero. Independiente o como un plugin de Visual Studio.

Java: Soy un fan de JProfiler. Nuevamente, puede ejecutarse de manera independiente o como un complemento de Eclipse (u otros IDE).

Creo que ambos tienen versiones de prueba.

3

Para aplicaciones complejas, soy un gran admirador de Intel Vtune. Es una mentalidad ligeramente diferente a un perfilador tradicional que instrumenta el código. Funciona al muestrear el procesador para ver dónde el puntero de instrucción es 1.000 veces por segundo. Tiene la gran ventaja de no requerir ningún cambio en tus binarios, lo que a menudo cambiará el tiempo de lo que estás tratando de medir.

Desafortunadamente, no es bueno para .net o Java, ya que no hay forma de que Vtune asigne el puntero de instrucción al símbolo como con el código tradicional.

También le permite medir todo tipo de otras métricas centradas de procesador/hardware, como relojes por instrucción, aciertos/errores de caché, errores/errores TLB, etc. que le permiten identificar por qué ciertas secciones de código pueden tardar más tiempo en ejecutar de lo que cabría esperar simplemente inspeccionando el código.

2

Si está haciendo un sistema 'en el metal' incrustado 'C' (no estoy muy seguro de qué implica 'móvil' en su publicación), entonces generalmente tiene algún tipo de ISR con temporizador, en el que es bastante fácil de probar la dirección del código en el que se produjo la interrupción (volviendo a buscar en la pila o mirando registros de enlaces o lo que sea). Entonces es trivial construir un histograma de direcciones en alguna combinación de granularidad/rango de interés.

Por lo general, no es difícil inventar una combinación de código/script/hojas de Excel que combina los recuentos de histograma con las direcciones de su archivo de símbolo/lista de enlazador para darle información de perfil.

Si tiene mucha memoria RAM, puede ser un poco doloroso recopilar suficientes datos para que esto sea simple y útil, pero debería contarnos más sobre su plataforma.

-1

¿Cómo van a funcionar las herramientas si su plataforma es un sistema operativo propietario? Creo que estás haciendo lo mejor que puede en este momento

6

que he hecho esto muchas veces. Si tiene un IDE o un ICE, there is a technique, eso requiere cierto esfuerzo manual, pero funciona sin falta.

Advertencia: los programadores modernos odian esto, y voy a obtener una votación negativa. Ellos aman sus herramientas. Pero realmente funciona, y no siempre tienes las buenas herramientas.

Supongo que en su caso el código es algo así como DSP o video que se ejecuta en un temporizador y tiene que ser rápido. Supongamos que lo que ejecuta en cada tic del temporizador es la subrutina A. Escriba un código de prueba para ejecutar la subrutina A en un bucle simple, digamos 1000 veces, o lo suficiente como para hacer esperar al menos varios segundos.

Mientras se está ejecutando, detenga aleatoriamente con una tecla de pausa y muestree la pila de llamadas (no solo el contador del programa) y grábela. (Esa es la parte manual.) Haga esto algunas veces, como 10. Una vez no es suficiente.

Ahora busque las similitudes entre las muestras de la pila. Busque cualquier instrucción o instrucción de llamada que aparezca en al menos 2 muestras. Habrá muchos de estos, pero algunos de ellos estarán en un código que podrías optimizar.

Hazlo y obtendrás una buena aceleración, garantizada. Las 1000 iteraciones tomarán menos tiempo.

La razón por la que no necesita muchas muestras es que no está buscando cosas pequeñas. Como si usted viera una instrucción de llamada en particular en 5 de 10 muestras, es responsable de aproximadamente el 50% del tiempo total de ejecución. Más muestras le dirían con mayor precisión cuál es el porcentaje, si realmente desea saberlo. Si eres como yo, todo lo que quieres saber es dónde está, para que puedas arreglarlo y pasar al siguiente.

Haga esto hasta que no pueda encontrar nada más para optimizar, y estará a su velocidad máxima o cerca de ella.

Cuestiones relacionadas