¿Qué hace para aumentar la velocidad de inicio (o para disminuir el tiempo de inicio) de su aplicación Delphi?¿Cómo aumentar la velocidad de inicio de la aplicación delphi?
Aparte de la aplicación específica, ¿existe un truco estándar que siempre funciona?
Nota: No estoy hablando de algoritmos rápidos o similares. Solo el rendimiento aumenta al inicio, en términos de velocidad.
Intente hacer lo menos posible en el evento OnCreate de su formulario principal. Más bien mueva alguna inicialización a un método diferente y hágalo una vez que se muestra el formulario al usuario. Un indicador de que la aplicación está ocupada con un cursor ocupado del mouse va un largo camino.
Los experimentos realizados muestran que si toma exactamente la misma aplicación y simplemente agrega una notificación de inicio, ¡los usuarios realmente perciben que la aplicación se inicia más rápido!
Aparte de eso, puede hacer las cosas habituales como excluir información de depuración y habilitar la optimización en el compilador.
Además de eso, no crea automáticamente todos sus formularios. Crearlos dinámicamente cuando los necesite.
En las opciones del proyecto, no cree automáticamente todos sus formularios por adelantado. Crea y libera según sea necesario.
+1 - y permítanme agregar: abra cualquier conexión, ya sea base de datos, Internet, COM o lo que sea, en el momento que lo necesite primero. –
@Uwe: su comentario es lo suficientemente claro como para haber sido una respuesta separada. Lo haría, excepto que parecería un sabueso rep, y aunque podría hacer que mi respuesta sea CW, pero entonces no obtendrías el representante. – Argalatyr
@Argalatyr: Gracias por la sugerencia –
suceden tres cosas antes de que aparezca el formulario: bloques
Como han señalado otros, debe crear automáticamente solo un número pequeño de formularios (especialmente si son formularios complicados con muchos componentes) y no debe poner un procesamiento extenso en los eventos OnCreate de esos formularios. Si, por casualidad, su forma principal es muy complicada, debe rediseñarla. Una posibilidad es dividir la forma principal en múltiples marcos que se cargan a pedido.
También es posible que uno de los bloques de inicialización tarde algún tiempo en ejecutarse. Para verificar, coloque un punto de interrupción en la primera línea de su programa (bloque principal 'begin..end' en el archivo .dpr) e inicie el programa. Se ejecutará todo el bloque de inicialización y luego el punto de interrupción detendrá la ejecución.
De forma similar, puede hacer el paso (F8) sobre el programa principal; verá cuánto tiempo tardará en crearse cada formulario creado automáticamente.
Bueno, como Argalatyr sugirió que cambie de comentario a una respuesta por separado:
Como una extensión de la respuesta "no crear automáticamente las formas" (que será muy eficaz por sí mismo) Sugiero a retrasar la apertura conexiones a bases de datos, Internet, servidores COM y cualquier dispositivo periférico hasta que lo necesite primero.
Muestra una pantalla de inicio, por lo que las personas no notarán los largos tiempos de inicio :).
Y actúa como una forma de marca de producto. –
Código más rápido: es el código que nunca se ejecuta. Muy obvio, realmente;)
Obvio ... cierto. Pero tampoco fue tan útil. – jpfollenius
El despliegue de la aplicación puede ocurrir (y normalmente lo hace) de maneras que el desarrollador puede no haber considerado. En mi experiencia, esto genera más problemas de rendimiento de los que nadie querría.
Un cuello de botella común es el acceso a archivos: un archivo de configuración, un archivo ini que se requiere para iniciar la aplicación puede funcionar bien en una máquina de desarrollador, pero funciona abismalmente en diferentes situaciones de implementación. De forma similar, el registro de aplicaciones puede impedir el rendimiento, ya sea por razones de acceso a archivos o por el crecimiento del archivo de registro.
Lo que veo a menudo son aplicaciones de cliente enriquecido implementadas en un entorno Citrix o en una unidad de red compartida, donde el equipo de infraestructura decide que los archivos temporales del usuario o los personales se almacenen en una ubicación donde la aplicación encuentra problemas , y esto conduce a problemas de rendimiento o estabilidad.
Otro problema que a menudo veo que afecta el rendimiento de la aplicación es el método utilizado para importar y exportar datos a archivos. Comúnmente, en las aplicaciones comerciales de Delphi veo funciones de exportación que funcionan fuera de DataSets: iterar y escribir en un archivo. Considere el método utilizado para escribir en un archivo, tenga en cuenta la memoria disponible, considere que la 'carpeta' desde la que se escribe/lee puede ser local para la máquina o puede estar en un servidor remoto.
Un desarrollador puede argumentar que estos son problemas de instalación, fuera del ámbito de su preocupación. Normalmente veo muchos ciclos de análisis de desarrolladores sobre este tipo de problema antes de que se identifique como un 'problema de infraestructura'.
¿Usar herencia para disminuir el tamaño de EXE? Eso me suena extraño ... quizás puedas explicar a qué te refieres. Y si sigue su primer punto, su último punto probablemente no sea necesario ... – jpfollenius
Digamos que tiene una aplicación de db de dos tablas. Y tiene dos formularios diferentes que enumeran datos básicamente. Y tiene controles que activan las operaciones CRUD usando otras formas. Si usa algunos patrones de diseño y elimina la 'lógica' de estos formularios, no crearía formularios para cada tabla. Pero aún así tienes razón al decir que mi primera y la última tienen alguna contradicción en cierto modo. Espero que esta explicación lo deje un poco claro. (Y decirte que lo hagas no significa que siempre pueda implementarlo con éxito :)) – user114285
insertar tareas de larga ejecución (conexiones de base de datos abierta, conectarse al servidor de la aplicación, etc.) que deben realizarse al inicio en un hilo. Cualquier funcionalidad que dependa de estas tareas está deshabilitada hasta que finalice el proceso.
Aunque es un poco engañoso. La forma principal aparece de inmediato, pero solo estás dando la apariencia de un tiempo de inicio más rápido.
Esto es solo para el IDE, pero Chris Hesick publicó un blog sobre increasing startup performance under the debugger.
Cada publicación del blog de Cris Hesick ha caído ahora ... :(Al menos aún podemos usar Archive.org ... Alguien debería volver a visitar estos temas en publicaciones de blog. – EMBarbosa
Entonces, ¿qué es una buena notificación de inicio? No me gustan las pantallas de bienvenida personalmente. ¿Qué más podría ser de todos modos? –
Cualquier cosa desde un mensaje de estado que le dice al usuario lo que está haciendo después de que su formulario principal se muestra con una pequeña etiqueta en algún lugar del formulario principal. Una barra de progreso también es útil si es posible, alternativamente una barra de progreso giratoria. – Maltrap
@utku Comprendo que no te gusten las pantallas de bienvenida, pero son útiles cuando el formulario principal no se muestra de inmediato. De lo contrario, es posible que su usuario no sepa que la aplicación se inició y trate de volver a ejecutarla. –