ayuda para lograr ejecutables pequeños
 

Hola a todos

Necesito me den criterios sobre mi proyecto.

Estoy haciendo una aplicación con muchos formularios, como es natural, el ejecutable final está aumentando de tamaño, todavía no voy ni por la mitad del proyecto y mi .exe pesa 40 Mb.

Cómo puedo solucionar eso??

Pensé en crear dlls con varios formularios afines, y me apareció un problema mayor: Esos formularios contenidos en las dll tienen componentes botones, TEdits, TComboBoxes, etc. No logro asociarle, por ejemplo, una función "contenida en la misma dll" a un boton, me da error.

No sé que hacer, tal vez con las dll no sea la solución.

Gracias

Hola,

No creo que lo que ocupen 40 MB sean los formularios como tales. Ni siquiera los componentes que haya en ellos. Se me ocurre que tal vez estés usando imágenes y que estas puedan ser más o menos optimizadas para que ocupen menos tamaño. Asegúrate también de que no estamos hablando del tamaño del ejecutable incluyendo información para su depuración. Si esto fuese así piensa que existe la opción para no incluir dicha información y así reducir el tamaño del programa ejecutable. Iba a añadir que tampoco debes preocuparte demasiado por el tamaño, puesto que si el programa ha de ocupar eso, habrá de hacerlo, pero, no significa que tenga que funcionar mal. Sin embargo, me parecen muchos 40 MB.

Gracias dec, ya le habia eliminado la info sobre depuración. Estimo que mi proyecto, que en realidad es un sistema de facturación con conexión a base de datos sql, comunicación tcp/ip ,impresión y etc. ronda por los 90 y pico de formularios, cargaditos de componentes, y tambien con imagenes de fondo, menús, bueno tu sabes...
Y no está pensado para PCs muy modernas. Yo vivo en Cuba. Y Algunas PCs son Pentium 3 con 128 Mb de RAM y micros de 500 MHz. Por eso estoy tratando de optimizar el proyecto al máximo.

Qué me dices de la opción de incluir los formularios en dll que iré cargando y descargando a medida que necesite esos forms???

Hola,

La opción que propones no parece algo sencillo, pero, mucho menos si partes de la base de tener que lidiar con 90 formularios que ya están trabajando de otra forma, no sé si me explico. Creo que debes más bien mirar el asunto de las imágenes. Es posible que estés usando Bitmaps pudiendo usar algo más liviano como JPG, por ejemplo. De todas formas no sé hasta qué punto un ordenador tiene más problemas con leer un Bitmap grande que no un JPG algo más pequeño de tamaño. Creo que el rendimiento de tu aplicación no debería verse comprometido por tener 90 formularios (aunque me parecen muchísimos) pero mira a ver si es que estás creándolos todos a la vez, procurando crearlos cuando sean necesarios y destruirlos cuando no lo sean.

^\||/^\||/^\||/

michal,

:rolleyes:

Pregunto:

1- ¿Que versión de Delphi utilizas?.

2- ¿Que versión de Windows utilizas?.

Te comento:

1- Lo viable en función de las características de hardware que mencionadas es Windows XP Professional x32 y Delphi 7.

2- El tamaño del ejecutable en memoria lo puedes disminuir al cargar los formularios dinámicamente como se sugirió en el Msg #4.

3- La opción de usar DLLs dinámicas para disminuir el tamaño del ejecutable en memoria es factible, revisa estos links:
Espero sea útil :)

Nelson.

Algo más
 

La mayoría de las PCs usan winXp sp3 de 32 bits y las más pobres usan win2k sp4
No uso Delphi sinó C++Builder 2009 aunque también tengo la versión 6.
Ya yo he logrado introducir los formularios en las DLLs pero no logro que una función, declarada en la DLL, poderla asociar a un botón que pertenezca a un formulario que esté dentro de esa misma DLL. Ese es principal problema de usar la solución de las DLL, que para ser sincero es la que más me gusta.
La otra la de crear formularios con sus componentes y luego destruirlos dinamicamente, al final el ejecutable crece igual y eso es lo que trato de evitar, debido a que mientras más grande es, más se tarda en cargar la aplicación. Y la opción de comprimirlo con el upx empeora la situación, pues demora mucho más la carga, debido a que primero tiene que descomprimirlo para luego ejecutarlo.

De todas formas, dices que vas por la mitad del proyecto. Cualquier optimización (sea de tamaño o de rendimiento) no debería realizarse hasta haber completado el programa. Una vez lo termines, ya sí, puedes ponerte a ver si consigues reducir tamaños.

De todas formas, el consejo de no crear todos los formularios y TData automáticamente es bueno. Lo que no sé es por qué está activado por defecto, cuando personalmente creo que debería ser al revés.

michal,

:rolleyes:

Te comento:

1- Te sugiero probar si un ejecutable en C++ Builder 6 con 40 formularios es menor en tamaño a uno creado con C++ Builder 2009, en Delphi se presenta el caso de que las versiones superiores a Delphi 7, generan ejecutables de mayor tamaño por la inclusión de nuevas librerías y/o cambios a las tradicionales.

2- En términos generales la información de creación de DLLs del Msg #6 es aplicable con sus correspondientes adaptaciones a C++ Builder.

Espero sea útil :)

Nelson.

Por intentar aportar algo se me ocurre que podrias en caso que al final no encuentres mas solución partir tu aplicación en varios modulos pero en lugar de hacerlos dll hacer propios ejecutables. No es una solución óptima ni mucho menos y ademas no se adapta a todas las situaciones. Pero si algún grupo de ventanas de la aplicación comienzan con una modal que debe de cerrarse antes de continuar con otra cosa bien puede ser un exe aparte (al que quizas deban de pasarsele algunos parámetros ciertamente).

Haciendo esto bien es verdad que es posible que acabes con un grupo de ejecutables que al sumar sus tamaños ocupen mas que tú ejecutable individual. Repito de nuevo que son mejores las otras opciones que están apuntando pero igual te vale la pena valorar lo que propongo.

Pienso también que 90 ventanas son muchas ventanas para una aplicación. ¿Seguro que realmente no tienes varias aplicaciones compiladas como una sola? Por ejemplo si tienes una aplicación desde la que se gestiona a los trabajadores de una empresa con sus nominas clientes, tareas pendientes etc, ademas de alamcenes con mercancía, albaranes facturación.... igual es mejor tener una aplicación de gestión de almacén, otra de facturación, otra de nomina, y otra de control de personal, aunque todas trabajen contra la misma bd.

un form es una clase con sus metodos y puedes crear el form en una dll con sus metodos y luego simplemente creas el form dinamicamente en tu ejecutable y podras acceder a sus metodos sin problemas. Eso si, para no liarte creas un .h donde declaras los eventos que usaras, metes lo que quieras que se haga en cada evento en el cpp de la dll y luego incluyes ese .h a tu main y con eso puedes acceder a todo.

La situación es sumamente simple y le están dando demasiadas vueltas.
Uno de mis sistemas más complejos tiene 72 formularios (sin contar principal, opciones, etc), y precisamente la que comentas es la que creo yo que es la mejor forma de gestionar las ventanas.

1, plantéate el uso de bpl’s en lugar de dll’s, la razón es que los bpl’s son exactamente iguales a las dll’s, solo que añaden el uso de RTTI y son un poco más estables al cargar y descargar de memoria (con la única desventaja de no ser estándar, es decir solo tu aplicación u otra aplicación Builder/Delphi, podrán consumirla).

2, en la dll o bpl, crea una unit (.cpp,.h), en la que contendrás las funciones que se exportaran e iniciaran los formularios, también estas pueden recibir parámetros o punteros de la BD, por ejemplo (a costa de la estandarización, cosa que no te debe preocupar si tu aplicación será la única que consuma la dll/bpl).
Cada función debe ser declarada en él .h de la siguiente manera:

Puedes buscar más información de que significa cada palabra, pero a grandes rasgos, estas declarando una función estándar que las otras aplicaciones podrán llamar, estas funciones son tal cual las funciones normales, es decir pueden devolver cualquier valor que requieras (otra vez a costa de la estandarización), o recibir cualquier cosa que requieras.

2.1, ya dentro de esta función creas el formulario y le pasas lo que necesites, en este caso “punteroEjemplo” que es el puntero del componente de la BD con el que se conectara tu componente de tabla o query.

3, ya en la aplicación principal en cualquier evento de botón va el siguiente código:

Pd. Esto debería compilar sin problemas, cualquier cosa comenta.

Creo que alguien sugirió antes, y preguntó, si crea todos los forms al comienzo o si los va creando según se van necesitando. Me parece que no he visto la respuesta a esa pregunta.
Alguna vez he comentado en algún mensaje que el último programa en el que estuve trabajando tenía cerca de mil formularios (1000) y no tenía ningún problema para funcionar en cualquier pc normal y corriente.