¿Cómo puedo averiguar la fuente de las largas demoras en el cambio de tamaño del formulario principal?

Question

Tengo una aplicación D2006 que contiene un control de página y varias cuadrículas, etc. en las pestañas. Cuando cambio el tamaño del formulario principal (que se extiende y cambia el tamaño de casi todo en el formulario que está alineado con algo), experimento largos retrasos, como varios segundos. La aplicación se congela, el controlador inactivo no se llama y los hilos en ejecución también parecen suspenderse.

He intentado detener la ejecución en el IDE mientras esto sucede en un intento de interrumpir la ejecución mientras está en el código problemático, pero el IDE no está recibiendo mensajes.

Obviamente no espero que nadie me señale un trozo de código errante, pero voy a depurar los enfoques que podrían ayudarme. Tengo un extenso código de tiempo de ejecución en toda la aplicación, y los largos retrasos no aparecen en ninguno de los datos. Por ejemplo, el tiempo de ejecución del controlador OnResize de forma principal es mínimo.

Answer 1

Si quiere saber qué es lo que realmente le está tomando su tiempo, intente con un generador de perfiles. Sampling Profiler podría responder a su pregunta con bastante facilidad, especialmente si puede encontrar el principio y el final de la sección de código que está causando problemas e inserte instrucciones OutputDebugString para reducir el perfil.

Answer 2

Un enfoque de fuerza bruta que puede arrojar resultados ... Ponga un mensaje de depuración en OutputDebugString() de cada evento de nuevo tamaño, enviando el nombre del control como la cadena que se mostrará. Esto puede mostrarle cuáles son llamados "mucho".

Es posible que tenga una situación en la que los controles se golpeen unos a otros, desencadenando eventos de cambio de tamaño en cascada. Al igual que 3 hermanos en el asiento trasero de un automóvil compacto, una vez que comienzan a empujar por una posición, les puede tomar un tiempo "calmarse".

No haga que vuelve este coche cerca de ....

El registro de depuración (visible en el IDE, o con un visor externo SAO), que pueden mostrar cuáles están causando más problemas, si aparecen varias veces para un "evento de cambio de tamaño iniciado por el usuario".

Answer 3

Ejecute su aplicación en el perfilador de rendimiento de AQTime (incluido con XE, pero puede obtener una versión de tiempo limitado de su sitio web).

Realice un cambio de tamaño fanático por un tiempo y luego detenga la aplicación.

Después de eso, verá exactamente qué función se invocó muchas veces y dónde se gastó la mayor parte del tiempo.

Answer 4

OK. Problema resuelto. Noté que el problema solo ocurría cuando tenía habilitados los modificadores de línea de comando para registrar alguna información de depuración. La información de depuración incluía algunas respuestas HTTP que se escribieron en un registro de depuración (un TMemo) en una de las pestañas. Cuando la respuesta HTTP incluía un bloque grande sin CR/LF, el TMemo lo envolvió. Cada vez que cambiaba el tamaño del formulario principal, el TMemo cambiaba de tamaño y el control tenía que volver a representar el texto con el nuevo ajuste de palabra.

Para demostrar:

• iniciar un nuevo proyecto Delphi
• caer una TMemo en la forma
• ajustarla a cliente
• compilar y ejecutar
• pegar una gran cantidad de texto el TMemo
• cambiar el tamaño del formulario principal

No me otorgaré la respuesta, ya que realmente no había proporcionado suficiente información para que nadie más la resolviera.

BTW @Mason - would SamplingProfiler ha elegido esto, dado que la ejecución está dentro de la VCL, y no en mi código?