¿Qué puedo hacer para reducir el tamaño de mi ejecutable(Delphi)?

build-process executable (15)

1) Está generando un archivo de mapa detallado, y porque ha configurado "dug de depuración usado", también contiene símbolos para las unidades RTL / VCL. Si es utilizado por un sistema de manejo de excepciones para generar pilas de llamadas y similares, podría agregarse al ejecutable. Y si no se comprime de alguna manera, podría hacer que su tamaño .exe sea bastante grande.

2) El uso de debug dcus también hará que su .exe sea algo más grande, ya que generalmente se compilan sin configurar las opciones de optimización y depuración, y también harán que su código sea más lento. No deberían usarse en una versión de lanzamiento.

3) La información de depuración debería agregar información de depuración solo a la unidad y no al ejecutable, aunque se requiere que IIRC genere el archivo de mapa.

Lanzo un solo archivo ejecutable (.EXE) para un programa de escritorio utilizando Delphi 2009. No tengo archivos DLL externos ni recursos que necesito para ejecutar el programa.

Utilizo dos componentes: ELPack de LMD Innovative y TRichView de Sergey Tkachenko que se compilan en mi ejecutable.

Cuando construyo mi versión de producción, usando la configuración de compilación "Release", el archivo ejecutable producido es 13,533 KB.

Antes de usar Delphi 2009, estaba usando Delphi 4. El ejecutable que producía era solo 2,671 KB mientras incorporaba los mismos dos componentes y básicamente tenía el mismo código que mi versión actual.

Entiendo que Delphi 2009 sea completamente Unicode (que es la razón principal por la que actualicé), y ser Unicode puede causar hasta el doble de tamaño. Pero esto es aproximadamente 5 veces más grande.

¿Hay alguna razón por la cual mi ejecutable debe permanecer 5 veces más grande? ¿O hay algunas formas simples de reducir un pedazo significativo del tamaño del ejecutable?

Tenga en cuenta. Algunas personas están respondiendo con formas de comprimir el EXE de Delphi. Eso no es lo que estoy tratando de hacer. Intento simplemente ver por qué se usa tanto espacio para eliminar lo que podría no ser necesario. Si eso se hace, la compresión aún se puede hacer después si así lo desea.

Realmente no importa cuán grande o pequeño sea el ejecutable una vez que esté instalado. Es para descargar y para minimizar la carga del servidor y los tiempos de descarga que desea comprimir. Prefiero usar Inno Setup y comprimir el programa dentro de la rutina de instalación. Luego, cuando está instalado, se expande a tamaño completo. Eso evita una posible detección como virus y elimina el tiempo de inicio adicional necesario para descomprimir el programa en la memoria. También codigo firmar tanto mi ejecutable como mi rutina de instalación y algunas técnicas de compresión son incompatibles con eso.

Para obtener más información sobre la compresión, consulte la pregunta de StackOverflow: ¿ Delphi EXE compressor?

ldsandon me pidió que le diera exactamente qué opciones estoy usando, así que aquí están:

Opciones de compilación http://www.beholdgenealogy.com/img/compilingoptions.jpg

Opciones de enlace http://www.beholdgenealogy.com/img/linkingoptions.jpg

Al pasar de Delphi 7 a Delphi 2010., nuestro .exe creció, por ejemplo, de 16 megas a 35 megas.

Hace unas semanas, hice una pregunta similar a la tuya en el foro de Embarcadero. ( link ) En mi PO, enumeré una serie de enlaces sobre este tema que podrían ser útiles.

Intentamos usar UPX para comprimir nuestros .exe. Dejarlo funcionar durante horas redujo significativamente nuestro .exe, pero probablemente no lo utilicemos en producción por estos motivos:

Tenemos bastantes .exe y no queremos esperar 1/2-día en cada compilación. (Es posible que podamos encontrar un conjunto de parámetros de fuerza no bruta para UPX que reduzca esto ...)
Aunque se reduce el tamaño del .exe, nuestro envío no fue posible, porque nuestro instalador (como es lógico) no puede extraer mucha más compresión del archivo ya comprimido ... mientras que pudo reducir el archivo original de 16 megas .exe a 8 megas
He leído algunos informes de que en algún momento (raramente, pero no nunca), el exe de UPX activó varios programas antivirus para informar que la aplicación contenía un virus. (No recuerdo la fecha, el sitio o los detalles de dónde vi esto, así que es un poco injusto por mi parte informarlo aquí). Pero somos tan adversos a arriesgarnos a que ocurra siquiera esa posibilidad, que UPX está fuera de la mesa ...

El enlace en el foro de Embarcadero también incluye un link a otro hilo SO sobre este tema.

Sigo estando sorprendido y decepcionado con el código inflado que encontramos al cambiarnos a Delphi 2010. Como señala Nick, 2X para Unicode es bastante excesivo.

Sin embargo, la hinchazón es una desventaja relativamente menor cuando se pasa a D2010, porque, IMO, D2010 es una mejora tan fabulosa en muchas otras formas. Pero significa que probablemente tendremos que pasar a enviar 2 CD en lugar de uno. No estoy esperando ver la reacción de nuestra organización hacia esto ...

Como D2010 agrega RTTI extendido, y RTTI es un factor notorio para aumentar el tamaño del exe, sería interesante ver qué tan grandes son los binarios D2009 para esa aplicación.

Si los binarios D2009 son significativamente más pequeños, no es Unicode, etc. Para mis propios binarios, solo tengo un aumento del 30% o más, pasando de D7 a D2009.

Desmarque la información de depuración en las opciones del proyecto. ¡Si embarcadero no puede proporcionar ninguna solución o explicación! Creo que la solución es simple: no se quede solo con Delphi, hay muchos lenguajes de programación, cada uno está limitado solo por la imaginación del programador.

Factoriza el aumento esperado de 2X de Unicode y terminas con un aumento de 2.5X no contabilizado. Esto tiene sentido teniendo en cuenta cuántas versiones ha omitido. Mucho se ha agregado a VCL y RTL desde Delphi 4, y no todo es material que se pueda unir fácilmente, incluso si nunca lo usas. Dependiendo de la cantidad de unidades que use, podría transportar un poco de equipaje extra.

Allen Bauer y el equipo del compilador agregaron una nueva característica en D2010 para ayudar a reducir esto , pero aparentemente están pisando con cuidado y no lo usaron en tantos lugares como pudieron. Con suerte, veremos más reducción de cruces en 2011 y versiones posteriores.

Hice algunas pruebas para ver la diferencia entre D2007 y D2010, porque estamos actualizando a D2010. He probado una aplicación de GUI de administración de tamaño mediano, con aproximadamente 60 formularios (cuadrículas con formularios de detalles, marcos, etc.). Estamos utilizando componentes TMS + Remobjects.

D2007:
compilación "normal": 18.8mb
con errores de depuración: 18.8mb (¡el mismo tamaño!)

D2010
normal: 23.9
debug dcu''s: 48.8mb (!)

Entonces usar debug dcu duplica nuestro tamaño de exe ...

Pruebe con nuestro servicio comercial (sin grandes dfm''s):
D2007: 12.3mb
D2010: 17.1mb

Así que sí, D2010 aumenta el exe (un poco), pero esto no es un problema para mi cliente.

Editar: alguna información sobre el tamaño compilado:
D2007:

D2010:

¡Así que un aumento del tamaño del código, pero más del doble de los datos!

Las unidades estándar en su delphi más reciente pueden contener más cadenas y constantes, como cadenas de error, que se incluyen incluso si deshabilita la información de depuración. Verifica tus usos.

No tiene muchas dudas además de no usar una unidad específica o eliminar datos innecesarios de ella.

(Mis experiencias son con Delphi 5)

Otra forma es echar un vistazo a "¿qué unidad aumenta el tamaño?".

Para hacer esto, utilizo el JCL ''Project Analyzer IDE'', integrado en el IDE con la instalación de JCL / JVCL, que muestra todas las unidades con su tamaño respectivo. Puede exportarlo en un archivo de texto. Si lo haces con los 2 entornos (D4 y D2009), tendrás mucha información pertinente.

Se ha dicho anteriormente que el uso de un compresor ejecutable reduce el tamaño del exe pero no del paquete de instalación. Sin embargo, si quieres un buen compresor, prueba ASPack .

@ Tom1952: ASPack es bastante rápido, solo unos segundos para comprimir un archivo

Si no quiere usar un compresor exe, entonces debería probar StripReloc .

Sin ver la configuración real que utiliza su configuración de compilación "Liberar" para explicar este aumento de tamaño, se necesita mucha especulación.

Más allá de algunos factores quizás poco probables que den como resultado un gran aumento en la cantidad de código que se "arrastra" aunque no se use, la magnitud de este aumento se explicaría más fácilmente mediante la inclusión de información de depuración.

Verificaría las configuraciones de compilador y enlazador para:

Información de depuración (configuración del compilador)
TD32 info (linker)
Información de depuración remota (vinculador)

Compare estas configuraciones en su proyecto Delphi 2009 con los equivalentes en Delphi 4.

También puedes cambiar el ícono. El icono en el nuevo IDE delphi (es decir, XE3) es compatible con Vista / 7 y contiene todos los tamaños (hasta 256x256 hasta donde yo sé). Por lo tanto, puede reducir el tamaño del archivo exe al cambiar el ícono.

Utilice "upx - comprima o expanda archivos ejecutables" @ http://upx.sourceforge.net

Si va a herramientas / configurar herramientas, y lo configura de esta manera, puede comprimir el ejecutable en el que está trabajando fácilmente a través de un elemento de menú en el IDE.

Verifique el formato de sus dfm-s. Deben estar en formato binario si desea que su exe sea más pequeño.

Voy a agregar mis pocas palabras. Linker puede eliminar procedimientos y funciones no utilizados solo si puede seguir la jerarquía del código. La lista de pesadillas para el enlazador se detalla a continuación:

Código basado en mensajes, la triste noticia es que este código no se puede eliminar en absoluto, es por eso que el tamaño del proyecto en blanco de Delphi continúa creciendo de una versión a otra. Cada nuevo mensaje de Windows (por ejemplo, WM_TOUCH siempre y cuando conozca la introducción reciente) crea una jerarquía de llamadas a procedimientos que no se puede eliminar (incluso si no tiene planeado usar Touch API en absoluto). Esto se debe a que cada caso WM_: fragmento es algo que el vinculador no puede decidir si se usará o no.
Código y estructuras de datos a las que se accede desde el comienzo, la inicialización y las finalizaciones de las unidades. Aquí tiene algo de control, elimina llamadas innecesarias o creación de objetos. Incluso si crea objetos a pedido y solo los libera en la sección de finalización, hágalo con cuidado