dyancer
asked on
Reducing the executable file SIZE !
Hello,
I'm using D3 to build an internal Viewer, the executable is about 400K. how can i further reduce the execuable file size.
Currently i do compile with "IO check" and "STACK check" and "Debug info" all set to false, i'm using the Optimize Code option.
thnx
I'm using D3 to build an internal Viewer, the executable is about 400K. how can i further reduce the execuable file size.
Currently i do compile with "IO check" and "STACK check" and "Debug info" all set to false, i'm using the Optimize Code option.
thnx
Maybe remove some unescesary units in your uses clause.
It depends on what you're trying to do, of course. But you can shrink the size of your executable considerably by building it with runtime packages.
This option is new with D3. It does a VB type compile and doesn't include all of your linked units into the executable. The downside (as with VB) is that you have to have the dynamic linked librariess available when you run the executable.
To do this, select Project>Options and go to the Packages tab. Check the 'Build with runtime packages' box and you're set.
This option is new with D3. It does a VB type compile and doesn't include all of your linked units into the executable. The downside (as with VB) is that you have to have the dynamic linked librariess available when you run the executable.
To do this, select Project>Options and go to the Packages tab. Check the 'Build with runtime packages' box and you're set.
ASKER
hppfff...
I'v tried your suggestion, and i found that
with the "build with runtime" option set the exeutable is 102K, but this executable need the VCL30.DPL to run that itself occupy 1.2M, it mean i need to deploy 1302K instead of the 400K i get when the "build with runtime" option not set.
I'v tried your suggestion, and i found that
with the "build with runtime" option set the exeutable is 102K, but this executable need the VCL30.DPL to run that itself occupy 1.2M, it mean i need to deploy 1302K instead of the 400K i get when the "build with runtime" option not set.
Have you tried ZifNab's suggestion?
ASKER
--------------------------
About ZifNab's suggestion...
Before i posted my question to the Expert-Exchange i'v done some work to reduce the size, here it for Other users to try to use...
1) Remove all unnecessary units "it helps only if you do add unnecessary units to your project though"
2) use the optimization program w8loss.exe found in delphi\bin " and it shrink 20% of the executable file size only if you don't use the "Optimize code" option found at Project|option|compiler|op
3) use some program to compress code like lzexe.exe or petite.exe , this programs further compress any .exe file about 50% and the file still executable without any need to decompress.
About ZifNab's suggestion...
Before i posted my question to the Expert-Exchange i'v done some work to reduce the size, here it for Other users to try to use...
1) Remove all unnecessary units "it helps only if you do add unnecessary units to your project though"
2) use the optimization program w8loss.exe found in delphi\bin " and it shrink 20% of the executable file size only if you don't use the "Optimize code" option found at Project|option|compiler|op
3) use some program to compress code like lzexe.exe or petite.exe , this programs further compress any .exe file about 50% and the file still executable without any need to decompress.
Hi dyancer, I have to say, I know of the earlier versions of Delphi (I don't know for the new ones) that Delphi itself added some units already to the forms which could be removed because they weren't used at all in the form! It just depends in what you all need. Delphi just added always the regular units to the user header in the beginning of creating your form, it sure doesn't know which one you will use.... Then again sometimes adding a new component adds a unit to the uses header. Removing it doesn't always removes this unit from the uses header...
ZiF.
ZiF.
But it's true, I guess that the newer versions of Delphi only compile the units which are needed if they are in the uses header are not. But then again, I don't know much of these things, I've never used them or really looked at it. ZiF.
Say, is it 400k after lzexe.exe or petite.exe???
ASKER
you guys respond very quick ;)
it's 400k before the petite.exe , the petite shrinks it down to 180k, but i need to compile ~100K.
then again, it's so important to me to reduce the executale size even if i should pay in the programme speed or something,
to say, this program is a viewer to my own email format, this format can display up to 30 deffernet languages, so whenever u send somebody an email containing languages not supported in the target windows then u would like to send him a viewer attached to the email itself... this attached viewer have-to-be as small and possible so the transmittion time be reduced
that's why i need to reduce the size so significantly.
any way... we are trying now to compile the program without using delphi FORMS, to say , direct api calls to create a window, i think it should do us the job...
TANX ALOT
it's 400k before the petite.exe , the petite shrinks it down to 180k, but i need to compile ~100K.
then again, it's so important to me to reduce the executale size even if i should pay in the programme speed or something,
to say, this program is a viewer to my own email format, this format can display up to 30 deffernet languages, so whenever u send somebody an email containing languages not supported in the target windows then u would like to send him a viewer attached to the email itself... this attached viewer have-to-be as small and possible so the transmittion time be reduced
that's why i need to reduce the size so significantly.
any way... we are trying now to compile the program without using delphi FORMS, to say , direct api calls to create a window, i think it should do us the job...
TANX ALOT
Seems to be an interesting program your working on. Let us know when you finished it. Thanks.
ASKER
if u really think it's intersting then feel free to email me at "niceguy25@geocities.com" and leave me your email address so i can notify you when we first release the programme.
Great idea in my oppinion too! Is Hebrew and Russian included? ;-)
my email is bosism@netvision.net.il
my email is bosism@netvision.net.il
This was taken from:
http://www.user.xpoint.at/r.fellner/dELPHIT2.HTM
Use CASE.. statments rather than IF..ELSE.. clauses.
>> Actually a two for one here, CASE statement are faster and smaller.
In every .PAS-file that will be linked in your project, place the following line to the top of your code:
{$D-,L-,O+,Q-,R-,Y-,S-}
Also add this line to your project source (.DPR).
{$D-} will prevent placing Debug info to your code.
{$L-} will prevent placing local symbols to your code.
{$O+} will optimize your code, remove unnecessary variables etc.
{$Q-} removes code for Integer overflow-checking.
{$R-} removes code for range checking of strings, arrays etc.
{$S-} removes code for stack-checking. USE ONLY AFTER HEAVY TESTING !
{$Y-} will prevent placing smybol information to your code.
After doing this, recompile the whole project - your .EXE-size should magically have been reduced by 10-20 %..
If you link in graphics, they don't need to have more than 16 or 256 colors.
If the goal is really and only .EXE size, load your graphics by code ("manually").
If you include resource-files, they should only content the resources you really need - and nothing more.
If you use Delphi 1, finally run W8LOSS.EXE on your .EXE file (not required for 32bit-Apps).
Delphi 2 produces larger .EXE sizes than Delphi 1 - 32 bit code demands its tribute..
Delphi 3 produces larger .EXE sizes than Delphi 2 - main reason: market pressure leads to more "fundamental" support of "bells and whistles" - quality and usefulness/efficiency/prod
check the "Show Hints" and "Show Warnings" options on the Project|Options|Compiler page, then rebuild your project. It will show you every variable and proc/func that isn't being used. You might be able to trim a little there, too.
Clean your USES.. clauses for all unneeded units !
The so-called "SmartLinking" doesn't always remove all unused code. In a large project you could possibly spare 100k in the EXE by that.
Place Bitmaps/Glyphs/etc. in DLL's instead of in *.RES/*.DCR files !
If you place fx some large bitmaps in a .RES, these will compiled into the EXE. Remove the .RES-declarations, instead place them in a new project like this:
LIBRARY My_Extern_RESes;
USES EmptyUnit;
{$R MyRes1.RES}
{$R MyRes2.RES}
...
INITIALIZATION
END.
The unit AEmptyUnit is a completely empty unit. You have to use a unit like this because any other unit will place unnecessary code in the final DLL. When you want to use an image (and typically, you only want to load it once), you can do it like this :
MyHandle := LoadLibrary('My_Extern_RES
TButton1.Glyph.Handle := LoadBitmap(MyHandle,'My_Gl
Placing Glyphs, Bitmaps, String-const's etc. in DLL's can really reduce a projects EXE-size. (Tip came from David Konrad)
Basis rule: the more forms and units you add, the larger your exe becomes. When you had one huge form, you only had one form class - even when you had 500+ things on it ! This creates only one runtime type information for that class. Now, when you split this into 17 units, each class in that unit requires its own RTTI. Now, this runtime information can get large, collectively, with a lot of redundant information compared to when you only had one huge class. Also, if each of the 17 units had its own form, your end product must contain resource information for all 17 of those forms even though most of that information may be redundant. One reason why this happens is because the Delphi compiler doesn't optimize resources - but I don't know of any compiler that does. So, if you had two separate forms which are identical in look, you'll have 2 copies of the resource in your .EXE.
This leaves some work for the programmer to be creative in maximizing resource reuseability. (Tip came from Young Chung)
http://www.user.xpoint.at/r.fellner/dELPHIT2.HTM
Use CASE.. statments rather than IF..ELSE.. clauses.
>> Actually a two for one here, CASE statement are faster and smaller.
In every .PAS-file that will be linked in your project, place the following line to the top of your code:
{$D-,L-,O+,Q-,R-,Y-,S-}
Also add this line to your project source (.DPR).
{$D-} will prevent placing Debug info to your code.
{$L-} will prevent placing local symbols to your code.
{$O+} will optimize your code, remove unnecessary variables etc.
{$Q-} removes code for Integer overflow-checking.
{$R-} removes code for range checking of strings, arrays etc.
{$S-} removes code for stack-checking. USE ONLY AFTER HEAVY TESTING !
{$Y-} will prevent placing smybol information to your code.
After doing this, recompile the whole project - your .EXE-size should magically have been reduced by 10-20 %..
If you link in graphics, they don't need to have more than 16 or 256 colors.
If the goal is really and only .EXE size, load your graphics by code ("manually").
If you include resource-files, they should only content the resources you really need - and nothing more.
If you use Delphi 1, finally run W8LOSS.EXE on your .EXE file (not required for 32bit-Apps).
Delphi 2 produces larger .EXE sizes than Delphi 1 - 32 bit code demands its tribute..
Delphi 3 produces larger .EXE sizes than Delphi 2 - main reason: market pressure leads to more "fundamental" support of "bells and whistles" - quality and usefulness/efficiency/prod
check the "Show Hints" and "Show Warnings" options on the Project|Options|Compiler page, then rebuild your project. It will show you every variable and proc/func that isn't being used. You might be able to trim a little there, too.
Clean your USES.. clauses for all unneeded units !
The so-called "SmartLinking" doesn't always remove all unused code. In a large project you could possibly spare 100k in the EXE by that.
Place Bitmaps/Glyphs/etc. in DLL's instead of in *.RES/*.DCR files !
If you place fx some large bitmaps in a .RES, these will compiled into the EXE. Remove the .RES-declarations, instead place them in a new project like this:
LIBRARY My_Extern_RESes;
USES EmptyUnit;
{$R MyRes1.RES}
{$R MyRes2.RES}
...
INITIALIZATION
END.
The unit AEmptyUnit is a completely empty unit. You have to use a unit like this because any other unit will place unnecessary code in the final DLL. When you want to use an image (and typically, you only want to load it once), you can do it like this :
MyHandle := LoadLibrary('My_Extern_RES
TButton1.Glyph.Handle := LoadBitmap(MyHandle,'My_Gl
Placing Glyphs, Bitmaps, String-const's etc. in DLL's can really reduce a projects EXE-size. (Tip came from David Konrad)
Basis rule: the more forms and units you add, the larger your exe becomes. When you had one huge form, you only had one form class - even when you had 500+ things on it ! This creates only one runtime type information for that class. Now, when you split this into 17 units, each class in that unit requires its own RTTI. Now, this runtime information can get large, collectively, with a lot of redundant information compared to when you only had one huge class. Also, if each of the 17 units had its own form, your end product must contain resource information for all 17 of those forms even though most of that information may be redundant. One reason why this happens is because the Delphi compiler doesn't optimize resources - but I don't know of any compiler that does. So, if you had two separate forms which are identical in look, you'll have 2 copies of the resource in your .EXE.
This leaves some work for the programmer to be creative in maximizing resource reuseability. (Tip came from Young Chung)
ASKER
**************************
we have reduced the size of the executable file to 75K... believe it or not...
we do reduce the size from 400K to 75K without loose of any of the program functionality,
and to you "Matvey"
yea sure...
i think we have some thing in common, i mean the HEBREW, We are an ISRAELI software company that devote it's work for developing programs that help people use the RTL writing direction including hebrew and arabic beside of many other LTR languages.
(for your information)
RTL stands for right to left.
LTR stands for left to right
we have reduced the size of the executable file to 75K... believe it or not...
we do reduce the size from 400K to 75K without loose of any of the program functionality,
and to you "Matvey"
yea sure...
i think we have some thing in common, i mean the HEBREW, We are an ISRAELI software company that devote it's work for developing programs that help people use the RTL writing direction including hebrew and arabic beside of many other LTR languages.
(for your information)
RTL stands for right to left.
LTR stands for left to right
ASKER
TO retnuh,
I don't know if i should give you the points, because you don't bring up any thing new to me or any thing that other users not posted as a comment...
I don't know if i should give you the points, because you don't bring up any thing new to me or any thing that other users not posted as a comment...
no problem, what other methods did you use, and where can I find petit.exe? I'm kind of in the same boat right now. I'm making a windows installer and a dos installer and putting them into one executable, so small executable size is must.
Great dyancer, I'm glad you finally made it.
What company is it you're developing for? In my oppinion there are lot's of things involving RTL languages that can be improved. Just lately for example I tried to write to a friend in Hebrew through Netscape, and we both saw the text inversed! It should be a really good idea to make an application like the one you've made.
BTW, how about the fonts? Are fonts included in it too? I saw some ideas of applications that don't use the standard fonts for text, instead they use their own images for building the text, which is of course almost the same as fonts except that it's not involving external files and installation. It's also easier if and creative...
Where are you within here by the way? I'm from Petach-Tiqa...
What company is it you're developing for? In my oppinion there are lot's of things involving RTL languages that can be improved. Just lately for example I tried to write to a friend in Hebrew through Netscape, and we both saw the text inversed! It should be a really good idea to make an application like the one you've made.
BTW, how about the fonts? Are fonts included in it too? I saw some ideas of applications that don't use the standard fonts for text, instead they use their own images for building the text, which is of course almost the same as fonts except that it's not involving external files and installation. It's also easier if and creative...
Where are you within here by the way? I'm from Petach-Tiqa...
ASKER
Thnx Matvey for your greetings...
Our programme is a mail Client, we are working now to build it as MAPI SERVER - "see my other question about mapi in this site",
this mail client work exactly as other mail clients (netscape mailer, eudora, pegasus and other) except for the nationalization idea, i mean you can send mail containg up to 30 deffrent languages AT THE SAME EMAIL...
also it include a virtual keyboard, it can spell check 9 languages and alot more...
about FONTS ... the user can choose to use any font installed in the system ( this should be carfully done, because the reciever person need to have these fonts installed also in his system) or to use our alternative build-in font so it is not a system dependent font.
(if u would like further information, please email me to niceguy25@geocities.com)
Our programme is a mail Client, we are working now to build it as MAPI SERVER - "see my other question about mapi in this site",
this mail client work exactly as other mail clients (netscape mailer, eudora, pegasus and other) except for the nationalization idea, i mean you can send mail containg up to 30 deffrent languages AT THE SAME EMAIL...
also it include a virtual keyboard, it can spell check 9 languages and alot more...
about FONTS ... the user can choose to use any font installed in the system ( this should be carfully done, because the reciever person need to have these fonts installed also in his system) or to use our alternative build-in font so it is not a system dependent font.
(if u would like further information, please email me to niceguy25@geocities.com)
Hello,
I'm not sure I've read everything, but why has no one sugested you don't use
the VCL at all ? This is the best method for reducing the exe size.
But for sure it's a pain to develop app like that. You have to do all the coding
by yourself like in the ancient time. Do all the message handling by hand.
But it will drastically reduce the exec size (yes i read you made what you wanted)
It's just to add a comment.
To get an example you can take a look at Delphi Zip, v1.40
you can get a copy here : http://www.geocities.com/SiliconValley/Network/2114/
In there you have the source code for a small program that is the
front end for an autodecompress zip file. With a small interface etc...
Very interesting to see what you can do without delphi ;)
But i can understand that if you hadd to do like that you won't be using delphi ;)
CU
I'm not sure I've read everything, but why has no one sugested you don't use
the VCL at all ? This is the best method for reducing the exe size.
But for sure it's a pain to develop app like that. You have to do all the coding
by yourself like in the ancient time. Do all the message handling by hand.
But it will drastically reduce the exec size (yes i read you made what you wanted)
It's just to add a comment.
To get an example you can take a look at Delphi Zip, v1.40
you can get a copy here : http://www.geocities.com/SiliconValley/Network/2114/
In there you have the source code for a small program that is the
front end for an autodecompress zip file. With a small interface etc...
Very interesting to see what you can do without delphi ;)
But i can understand that if you hadd to do like that you won't be using delphi ;)
CU
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
hello DPedrelli.
thanx alot for trying to help, but, i want you to notice that
1) you came long time after i already success to solve the problem.
2) you say nothing new, i mean , u repeat what other experts said.
3) i cant give you the points...
<NOTICE > this question is to consider Deleted/solved/PAQ.
dyancer
thanx alot for trying to help, but, i want you to notice that
1) you came long time after i already success to solve the problem.
2) you say nothing new, i mean , u repeat what other experts said.
3) i cant give you the points...
<NOTICE > this question is to consider Deleted/solved/PAQ.
dyancer
Hi dyancer, how is it going, any news with the project?
You were also speaking about a friend of yours that could give me a hand with my DSP project...
Yours, Matvey
You were also speaking about a friend of yours that could give me a hand with my DSP project...
Yours, Matvey
ASKER
Hey Matvey,
The project is almost done,
you can download a demo version at www.lingomail.com
about the buddy who made a DSP project, he got married, and now he is enjoying his HONEY-MOON :)
i'm sending you an email as well..
hope to hear from you soon.
dyancer.
The project is almost done,
you can download a demo version at www.lingomail.com
about the buddy who made a DSP project, he got married, and now he is enjoying his HONEY-MOON :)
i'm sending you an email as well..
hope to hear from you soon.
dyancer.