Por qué ocupan tanto los ejecutables creados con Firemonkey?

cocute · #1 02-12-2012

Por qué ocupan tanto los ejecutables creados con Firemonkey?
Creando un form firemonkey totalmente en blanco en XE3,
En Release ocupa 8,2mb y en Debug 18mb.
Es normal esto?
Hay algún modo de configurar algo para que no ocupen tanto?

Ñuño Martínez · #2 03-12-2012

No uso Delphi XE3, pero seguro que hay alguna opción en la configuración del compilador que puedes activar. Por ejemplo (al menos con Lazarus, que es lo que más uso ahora) hay una opción "strip" que elimina toda la información que no tenga que ver con la ejecución.

Otra posibilidad es que estés usando RTTI (identificación del objetos en tiempo de ejecución, entendiendo "objeto" en el sentido clásico), algo que suele hinchar mucho el ejecutable ya que almacena el nombre de clases, tipos, registros... incluso si no se usa depuración. Si no es necesario, deberías revisarlo y no usarlo (por ejemplo, no usar "... AS <tipo>" y usar "<tipo> (...)" en su lugar, salvo que haya una buena razón).

Por último, posiblemente estés mezclando FireMonkey con el viejo VCL. Nunca he usado FireMonkey, pero si no lo entiendo mal es un sustituto de VCL, por lo que no deberían usarse los dos a la vez.

cocute · #3 06-12-2012

No, al crear un proyecto Firemonkey las VCL no se cargan, se carga esto:

Poniendo sólo esto en el uses
FMX.Forms;
no varía nada el tamaño que poniendo más librerias FMX que no se usan.

Poniendo esto, he conseguido reducir 1mb o así pero entiendo que 7,6mb siguen siendo muchos megas para un proyecto vacío.

{$IF CompilerVersion >= 21.0}
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
{$IFEND}

cocute · #4 06-12-2012

tiene que ser algo que tengo mal configurado en los proyectos creados por defecto.

Ya que he bajado un ejemplo hecho con firemonkey y al compilarlo se me queda en unos 1,7mb.

tendré que investigar en el fichero .dproj aunque hay tantas cosas ahí que no se cual puede ser

cocute · #5 24-12-2012

acabo de descubrir un packer que funciona mejor que el UPX,
vamos un ejecutable de 10mb que el UPX me lo dejaba en 2682kb
el mpress este me lo deja en 1937kb

Lo bueno que tiene además este packer es que sirve también para programas compilados en 64bits
y para programas compilados para OSX (bueno comprimirlos los comprime, probarlos no los he probado.)

es el:
http://www.matcode.com/mpress.htm

Creeis que son recomendables estos packers? ya que me imagino que al tener que descomprimirse en tiempo de ejecución
demoran un pelín el arranque del programa, aunque normalmente sea insignificante.

Ñuño Martínez · #6 24-12-2012

Una pequeña "desventaja" de ese mpress es que "sólo" es compatible con Windows y MacOS. Una pena, porque siempre vienen bien estas competencias.

Respecto a si es recomendable o no, pues depende de cada caso. Si no hay necesidades especiales de memoria ni velocidad, pues ¿por qué no?

MAXIUM · #7 16-01-2013

Cita:

Empezado por cocute

acabo de descubrir un packer que funciona mejor que el UPX,
vamos un ejecutable de 10mb que el UPX me lo dejaba en 2682kb
el mpress este me lo deja en 1937kb

Lo bueno que tiene además este packer es que sirve también para programas compilados en 64bits
y para programas compilados para OSX (bueno comprimirlos los comprime, probarlos no los he probado.)

es el:
http://www.matcode.com/mpress.htm

Creeis que son recomendables estos packers? ya que me imagino que al tener que descomprimirse en tiempo de ejecución
demoran un pelín el arranque del programa, aunque normalmente sea insignificante.

Mmmm... no, no es recomendable en el sentido que esos 10mb, aunque este comprimidos a 2,62mb, seguirán siendo 10mb, ya que al ejecutarlos, se descomprimen en memoria hasta los 10mb que ocuparían originalmente.

Estos tipos de compresión solo sirven para transportar un ejecutable de menor tamaño y de algún modo básico "proteger" el ejecutable

cocute · #8 16-01-2013

Cita:

Empezado por MAXIUM

Mmmm... no, no es recomendable en el sentido que esos 10mb, aunque este comprimidos a 2,62mb, seguirán siendo 10mb, ya que al ejecutarlos, se descomprimen en memoria hasta los 10mb que ocuparían originalmente.

Estos tipos de compresión solo sirven para transportar un ejecutable de menor tamaño y de algún modo básico "proteger" el ejecutable

Pero que sentido tiene que haya dentro de un ejecutable por ejemplo 1mb seguido que es todo ceros?
Por qué no se optimiza más el tamaño los ejecutables al compilarse?
Cierto es que cada día es menos importante el tamaño, pero tampoco es como para derrocharlo sin razón.

MAXIUM · #9 16-01-2013

Cita:

Empezado por cocute

Pero que sentido tiene que haya dentro de un ejecutable por ejemplo 1mb seguido que es todo ceros?
Por qué no se optimiza más el tamaño los ejecutables al compilarse?
Cierto es que cada día es menos importante el tamaño, pero tampoco es como para derrocharlo sin razón.

Creo que deberias comprender en forma básica lo que significa la compresión de un archivo.

Por otra parte, un ejecutable exageradamente grande en comparación, es porque contiene información innecesaria como librerias que cargan otras librerias y funciones que no se usaran.

El problema biene desde decadas atras y se usaban técnicas para quitar cosas del código para que no enlazaran cosas que no se iban a usar, pero hoy en día hay mucho código "sobre cargado".

Imagina que cargas una librería de 1mb y de ella solo usaras una función que pesa apenas 30kb, ¿no sería mejor darse el trabajo de escribir ese código por separado?.

Bueno, todo depende del lenguaje que se utilice. Por ejemplo, una vez tuve en computador a modo de prueba, un sistema operativo con interface gráfica, aplicaciones básicas y todo en unos cuantos kilobytes, más aún, compilado a 64bit. Estaba programado enteramente en assembles

En tu caso práctico, revisa las opciones de compilación del proyecto. No se sobre Firemonkey, pero a lo menos en Lazarus me ayudo a bajar de 8mb a 1mb en una aplicación básica.

[Al González] · #10 16-01-2013

MAXIUM, me parece que tienes mal concebido cómo afectan las dependencias entre bibliotecas y funciones a la compilación de un proyecto.

Cita:

Empezado por MAXIUM

[...] un ejecutable exageradamente grande en comparación, es porque contiene información innecesaria como librerias que cargan otras librerias y funciones que no se usaran.

Esto es absolutamente falso, al menos en Delphi y otros buenos compiladores.

Para explicarlo de forma sencilla, cuando se crea un módulo ejecutable, dentro de él solamente se incluyen los métodos y las funciones que el programa potencialmente empleará para su ejecución. Si usas una clase T1, que tiene tres métodos públicos: Proc1, Proc2 y Proc3, y ninguna línea del código fuente del programa hace referencia a Proc2 (ni a otro elemento que requiera de Proc2), ese método no será compilado ni incluido dentro del ejecutable, precisamente porque no se usa. Y lo mismo ocurre con las funciones "sueltas" de una biblioteca a las que el programa no haga referencia directa o indirectamente.

Cita:

Empezado por MAXIUM

Imagina que cargas una librería de 1mb y de ella solo usaras una función que pesa apenas 30kb, ¿no sería mejor darse el trabajo de escribir ese código por separado?

Si es una biblioteca DLL no hay discusión, toda la DLL se carga. Pero si con "librería" te refieres a una biblioteca de clases / funciones en código fuente, sólo se ha de incluir en el ejecutable lo que el programa necesita.

Cita:

Empezado por MAXIUM

Bueno, todo depende del lenguaje que se utilice.

Así es, y el compilador de Delphi está bastante bien diseñado para evitar incluir código innecesario en los ejecutables.

Por otra parte, comparto la idea de que hay que buscar en las opciones de compilación, revisar qué código es el que se está incluyendo al usar FireMonkey, y además qué posibles recursos se están enlazando, para intentar encontrar la razón del tamaño de esos ejecutables.

Saludos aclaratorios y desmitificadores.

Al González.