Por qué ocupan tanto los ejecutables creados con Firemonkey?

[Ñuño Martínez]

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]

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]

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]

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]

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]

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]

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.