already delphi win32 exe size is ~850 kb , do they have any roadmap of making exe size bit smaller,(i know that the size is because of vcl unicode RTTI and many more ),delphi compiles the whole unit even only a small function in the unit is needed. so is there any facilities to do so,or third party products are there , (i know kol and mck do the same)
Asked
Active
Viewed 728 times
2
-
delphi 2010 has guesture support and unicode but if i dont want can i leave it and compile it – Vibeeshan Mahadeva Oct 30 '10 at 09:54
-
kol and mck are nice but lack of facilities and no support after d7 – Vibeeshan Mahadeva Oct 30 '10 at 10:07
-
7Ten years ago, a 10 GB harddisk can store 100000 of such programs. Nowadays, the range is in Terrabytes; do your calculation. Premature optimization is the root of all evils (D.E. Knuth). – Lie Ryan Oct 30 '10 at 11:26
-
@Lie: how is it premature when he already has an application of which he knows the size? At least from the size of a rather simple Win32 program throughout the evolution of the Delphi compiler we can conclude that the so-called "smart linker" has become *a lot* dumber with time ... besides, I'm glad for you, that only store programs on your disk, on mine data takes by far the biggest share, so I don't want huge programs. Still Delphi's approach is certainly more desirable than C#/.NET, although the latter one was designed by the same guy. – 0xC0000022L Jan 07 '12 at 12:32
-
@STATUS_ACCESS_DENIED: so I have a 500GB disk (not uncommon these days, rather on the low side), my executable is an extremely large and extremely complex and the linker sucks and the program takes 100 MB of pure code, and after years of research I invented a way to reduce that size by 99%. What did I save? 0.01% of my harddisk space; great I can really use that to store more of my data. – Lie Ryan Jan 07 '12 at 19:56
-
@STATUS_ACCESS_DENIED: as you said it yourself, data is the one that takes the most space; not programs. Video, Images, Music, all that takes much more space than programs, they're the low-hanging fruits. If you had time to spend on finding ways to make things smaller, you'll get much higher payoff by reducing the size of multimedia data. – Lie Ryan Jan 07 '12 at 20:09
-
2@Lie: you're dodging the argument at hand. There is no logical reason why the binaries should grow this dramatically, even with the Unicode migration factored in. VS2010 proves that code doesn't have to grow with new compilers. – 0xC0000022L Jan 09 '12 at 20:42
-
@STATUS_ACCESS_DENIED true it's dodging the argument, but when disk space is so plentiful nowadays, the subject matter of optimizing binaries for size becomes moot. The only valid reason I see for optimizing for size is that they're faster to load from disk, but that's assuming that the smaller binaries doesn't cause you to be loading twenty additional libraries. – Lie Ryan Jan 09 '12 at 23:47
-
2@Lie: you don't think smaller binaries mean less code and would agree that the fastest code is the one that doesn't have to be run? This is my main point. I realize that for economic reasons one has to trade off some speed or size for faster development or better maintainability. But only so far. No one has yet come up with a logical reason why a program compiled with Delphi 7 is four times smaller than the binary built with Delphi XE, for example. Unicode is no compelling reason either, because most of the related bloat would be in the VCL, this code is not using VCL though. – 0xC0000022L Jan 12 '12 at 17:03
5 Answers
11
I doubt that exe size is much of a concern for the Delphi team, or even for most of the users as well. As you noticed, unicode and new RTTI increase the size, and while you can turn of new RTTI there really is not much else you can do about it.
In general each new Delphi version produced larger exes, I don't see this trend changing.
As for compiling whole units that isn't correct, unless you compile packages the compiler will not include non used methods and declarations.
If exe size is important you don't have much choice. If you don't need unicode and other new features then using D2007 or D7 or even D2 is an option.
You can use exe packers such as UPX.
If you build a set of applications you can reduce total size by using shared packages.
Also check out these:
Community
- 1
- 1
-
"I doubt that exe size is much of a concern for the Delphi team, or even for most of the users as well." I would agree. Until you get into the many-megabytes range, there's no real slowdown. – ssube Nov 02 '10 at 04:03
2
I'm not sure what kol and mck have to do with your question about .EXE size.
The presumption in your question that a unit is always completely included in your .EXE, even if only a small portion of the unit is actually used, is plain wrong.
Delphi has both a code optimizer and a linker optimizer.
The latter will not include code from a unit in your .EXE if that code is not actually somehow used.
Your more general question 'do they have any roadmap of making exe size bit smaller' can be answered by a simple 'No'.
The current roadmap does not include that.
--jeroen
Jeroen Wiert Pluimers
- 23,965
- 9
- 74
- 154
0
You certainly shouldn't expect exe size for future 64-bit Delphi versions to be smaller than current 32-bit Delphi exe files.
On the contrary: pointers and pointer-sized types will double in size and other data structures may grow in size due to padding (to meet alignment requirements). All of this gets compiled into the executable, the size of which will therefore grow.
PhiS
- 4,540
- 25
- 35
0
The path looks to be exes will become larger, in the future. Application size became far less important since disk sizes, bandwith and memory footprint rarely are a problem in the Windows world. There's always been a tradeoff between exe size and exe optimization (some optimization techniques can make an exe larger), and a 64 bit executable will probably be somewhat larger. Also improvements to the language may require more data to be stored about the code itself (i.e. RTTI informations). There are techniques to keep an exe size small, but they usually require to bypass most of the Delphi OOP and RAD features and libraries. Unless you have very special needs, rarely the exe size is an issue (although I understand that is some parts of the world bandwidth still matters, and maybe disk space too).
Anyway AFAIK it is not true Delphi linker will import a whole unit. Unused calls will be removed, although not everything you would like to be. The dcu will be compiled as a whole, but only needed code will be moved to the compiled executable. Something may depend on your compilation options. Did you activate the optimization option?
