2009-12-26 37 views
14

Tengo un programa que se ejecuta bastante lento (tarda unos 20 segundos incluso en el lanzamiento) así que, queriendo arreglarlo, traté de usar el generador de perfiles integrado de Visual Studio. Sin embargo, cuando ejecuto el programa con el perfil habilitado, finaliza en menos de un segundo. Esto hace que sea muy difícil encontrar un cuello de botella. Publicaba el código pero es largo. ¿Hay alguna razón obvia o no tan obvia de por qué esto estaría sucediendo?¿Por qué mi programa se ejecuta mucho más rápido cuando habilito la creación de perfiles?

EDIT: Ok, reduje el problema a un grupo de llamadas gratuitas(). Cuando los comente, el programa se ejecuta en la misma cantidad de tiempo que lo hace con el perfil habilitado. Pero ahora tengo una pérdida de memoria: -/

+4

Posiblemente sea una forma extraña de efecto Heisenberg (http: // en.wikipedia.org/wiki/Werner_Heisenberg). Sabe que estás mirando y se pone de pie y se pone a trabajar. :-) –

+1

Supongo que sucede por la misma razón que el error que siempre ocurre en el mismo punto del programa, excepto cuando lo ejecuta en el depurador. – sepp2k

Respuesta

10

Suena muy parecido a Heisenbug.

Realmente suceden, y pueden ser dolorosos de descubrir.

Su mejor solución en mi experiencia es cambiar la forma en que está perfilando - posiblemente varias formas - hasta que el error desaparezca.

Use diferentes perfiladores. Intente agregar el código de tiempo en lugar de usar un generador de perfiles.

+3

+1 para el enlace entretenido –

0

La manera general sería dividir y conquistar, es decir, ejecutar solo partes del programa y ver cuando el problema desaparece. Pero parece que ya hiciste eso. AFAIK gratis generalmente no toma mucho tiempo, pero malloc puede tomar mucho tiempo si la memoria está fragmentada. Si no llama a free(), el montón nunca se fragmenta en primer lugar. (El código intrusivo de creación de perfiles podría evitar la fragmentación de la memoria al asignar pequeños bloques de datos y llenar los vacíos libres, pero admito que es una explicación poco convincente).

Tal vez pueda agregar llamadas de medición de tiempo manuales antes/después de las llamadas a malloc y nuevas e imprimir las horas para verificar eso? Tal vez también pueda analizar sus patrones de asignación de memoria para averiguar si tiene un problema de fragmentación del montón (probablemente al mirar el código y realizar una depuración simbólica en su cabeza ;-)

5

encender el perfilador terminará moviendo su código alrededor (un poco) que probablemente enmascara el problema.

La causa más común de hiesenbugs son las variables unitarias, la segunda causa más común es utilizar la memoria después de haber sido liberada(). Dado que su versión gratuita parece arreglarlo, puede pensar en buscar referencias tardías, pero aún así buscaría variables sin inicializar si fuera usted.

0

Utilice un generador de perfiles de muestra no intrusivo en lugar de un intrusivo perfilador instrumentado.

+1

Estoy usando el muestreo – Stewart

0

Puede deberse a que el compilador no realiza algunas optimizaciones cuando lo ejecuta en modo de creación de perfiles. Por lo tanto, sugiero que verifique los parámetros que se pasan y consulte la documentación del compilador.

22

El motivo se debe a que cuando ejecuta la aplicación en Visual Studio, el depurador se adjunta. Cuando lo ejecuta utilizando el generador de perfiles, el depurador no está conectado.

Si presiona F5 para ejecutar su programa, incluso con la compilación Release, el depurador aún está conectado.

Si intenta ejecutar el .exe solo, o ejecuta el programa a través del IDE con "Debug> Start Without Debugging" (o simplemente presione Ctrl + F5), la aplicación debe ejecutarse tan rápido como lo hace con el generador de perfiles.

+0

¡Gracias! Realmente me ayudó, ¡pero en otro caso! – STiLeTT

+1

Absolutamente correcto, esta debería ser la respuesta aceptada. – cid

Cuestiones relacionadas