Depuración visual utilizando >>,>,> |, ||, | <, <, <<

Question

La depuración de problemas de rendimiento con un depurador estándar es casi imposible ya que el nivel de detalle es demasiado alto. Otras formas son el uso de un generador de perfiles, pero rara vez me dan buena información, especialmente cuando hay una GUI y subprocesos implicados, ya que nunca sé si el usuario estaba realmente esperando la computadora, o no. Una forma diferente es simplemente usar Control + C y ver en qué parte del código se detiene.

Lo que realmente me gustaría es tener funciones de avance rápido, reproducción, pausa y rebobinado combinadas con alguna represión visual del código. Esto significa que podría configurar el código para que se ejecute en Avance rápido hasta que navegue por la GUI hasta el punto crítico. Luego configuro el código para que se ejecute en modo lento, mientras obtengo una representación visual de las líneas que se están ejecutando (posiblemente algún tipo de vista alejada del código). Podría, por ejemplo, establecer la velocidad de ejecución a algo así como 0.0001x. Creo que obtendría una visualización muy buena de este modo si el problema está dentro de un módulo específico, o tal vez en la comunicación entre módulos.

¿Existe esto? Mi necesidad específica está en Python, pero me gustaría ver dicha funcionalidad en cualquier idioma.

Answer 1

La función "Avance rápido a punto crítico" ya existe en cualquier depuración, se denomina "punto de interrupción". De hecho, hay depuradores que pueden ralentizar la ejecución, pero eso no ayudará a depurar los problemas de rendimiento, ya que no ralentiza la computadora. El procesador y el disco y la memoria siguen siendo tan lentos como antes, todo lo que sucede es que el depurador inserta retrasos entre cada línea de código. Eso significa que cada línea de código tarda más o menos al mismo tiempo, lo que significa que oculta cualquier rastro de dónde está el problema de rendimiento.

La única forma de encontrar los problemas de rendimiento es registrar cada llamada realizada en la aplicación y cuánto tiempo tomó. Esto es lo que hace un perfilador. De hecho, usar un generador de perfiles es complicado, pero probablemente no haya una mejor opción. En teoría, podría grabar cada llamada y el tiempo de cada llamada, y luego reproducirla hacia adelante y hacia atrás con un rebobinado, pero eso usaría una cantidad asombrosa de memoria, y en realidad no le diría nada más de lo que lo hace un generador de perfiles (de hecho, le diría menos, ya que perdería ciertos tipos de problemas de rendimiento).

Debería poder, con el generador de perfiles, descubrir lo que está tardando mucho tiempo. Tenga en cuenta que esto puede ser tanto por ciertas llamadas a funciones que tardan mucho tiempo porque procesan mucho, o puede ser que las llamadas al sistema que toman mucho tiempo se conviertan en algo (red/disco) sea lento. O puede ser que una llamada muy rápida se llame cargas y muchas veces. Un perfilador te ayudará a resolver esto. Pero ayuda si puede activar el generador de perfiles solo en la sección crítica (reduce el ruido) y si puede ejecutar esa sección crítica muchas veces (mejora la precisión).

Answer 2

Supongo que hay una fase en la ejecución de la aplicación que lleva demasiado tiempo, es decir, te hace esperar. Supongo que lo que realmente quiere es ver lo que podría cambiar para hacerlo más rápido.

Una técnica que funciona es random-pausing. Ejecuta la aplicación bajo el depurador y en la parte de su ejecución que lo hace esperar, pausarlo y examinar la pila de llamadas. Haz esto algunas veces.

Aquí hay algunas formas en que su programa podría estar pasando más tiempo de lo necesario.

• E/S que no conocía ni necesitaba realmente.
• Asignación y liberación de objetos con mucha frecuencia.
• Notificaciones fugitivas en las estructuras de datos.
• otros demasiado numerosos para mencionarlos ...

No importa lo que es, cuando está sucediendo, un examen de la pila de llamadas se mostrará. Una vez que sepa de qué se trata, puede encontrar una manera mejor de hacerlo, o tal vez no hacerlo en absoluto.

Si el programa tarda 5 segundos cuando podría tomar 1 segundo, entonces la probabilidad de que vea el problema en cada pausa es de 4/5. De hecho, cualquier llamada de función que vea en más de una muestra de la pila, si puede evitar hacerlo, le dará una aceleración significativa. Y, casi todos los posibles cuellos de botella se pueden encontrar de esta manera.

No piense en los tiempos de función ni en cuántas veces se llaman. Busque líneas de código que aparecen a menudo en la pila, que no necesita.

Ejemplo agregado: Si toma 5 muestras de la pila, y hay una línea de código que aparece en 2 de ellas, entonces es responsable de aproximadamente 2/5 = 40% del tiempo, dar o tomar. Usted no sabe el porcentaje exacto, y no necesita saber. (Técnicamente, en promedio es (2 + 1)/(5 + 2) = 3/7 = 43%. No está mal, y usted sabe exactamente dónde está.)

Answer 3

Los métodos que está describiendo, y muchos de los comentarios, me parece que son intentos probabilísticos relativamente débiles para comprender el impacto en el rendimiento. Los perfiladores funcionan perfectamente para GUI y otros programas de subprocesos inactivos, aunque requiere un poco de práctica leerlos. Creo que su mejor apuesta está allí, sin embargo, aprenda a usar mejor el perfilador, para eso sirve.

El uso específico que describes simplemente sería adjuntar el generador de perfiles pero no registrarlo todavía. Navega la GUI hasta el punto en cuestión. Presione el botón de registro del perfilador, realice la acción y pare la grabación. Ver los resultados Fijar. Hazlo otra vez.