Compiler: Size of generated executable file

[retard]

Sun, 10 Jan 2010 16:45:56 -0500, bearophile wrote:

> Chris:
>> Execution speed perhaps, since the time elapsed is proportional to the
>> number of processor instruction executed. This explains why some people
>> (for certain time critical apps) do not even take the step from C to
>> C++, and chose to stay 20 year behind "modern" languages.
> 
> In real programs what takes time are (beside I/O and cache issues that
> are another form of I/O) often small amounts of code, usually loops
> inside loops. Removing a single instruction inside them can reduce the
> running time by K%, while removing a megabyte of code elsewhere may just
> reduce a little the loading time, etc.
> 
> 
>> D presented itself being a high level language suitable for system
>> programming, so executable sizes must be taken into consideration,
>> imho.
> 
> I don't think we'll see miracles soon, but D2 is currently in alpha
> state still. Once it's in beta some care will be probably given to
> optimizations too, and among them there is the executable size too. Even
> if most people don't need such optimization, it's clearly
> psychologically required by C/C++ programmers. Eventually it's even
> possible to add a compilation flag to D compilers to not use the GC,
> avoiding that overhead on C-like programs (such flag must also turn some
> operations into compilation errors, like array join, etc, to avoid
> leaks). Currently Link Time Optimization of LLVM (that can be used by
> LDC) removes some unused code from D1 programs.

At least you're admitting that a problem really exists. Some D users even 
see the problems as important and desired features - "Your exe consumes 
500 MB of space? But that's a good thing. Now you can be certain that you 
have a valid reason for finally purchasing that 10 TB raid-5 array."