On 24.02.2011 19:41, Walter Bright wrote:

>>> The nice thing is reduction in half of the resulting binary size.
>>
>> That's indeed nice! The unnecessarily huge size of binaries created
>> with D / Optlink was in fact something hindering me to use D at all!
>
> I'm sure that linker is doing it by writing compressed exe's. This means
> that it has the same memory footprint, and it loads slower because it
> must be decompressed. Also, if you store it in a zip file, the zip file

IMHO, that is a common misbelief when it comes to executable compressors. AFAIK, the time required for decompression is overcompensated by the time required to read less data from disk, even still nowadays.

> won't be any smaller because recompressing compressed data doesn't make
> it smaller.

There really needs to be no compression or back magic involved to make the executable size for a simple program like

---8<---

import std.stdio;

void main(string[] args)
{
    writeln("Hello World, Reloaded");
}

---8<---

smaller than the current 286 KiB! Some dead code elemination would already do, I guess.

-- 
Sebastian Schuberth

On 2011-02-26 06:10:19 -0500, Sebastian Schuberth <sschuberth@gmail.com> said:

> On 24.02.2011 19:41, Walter Bright wrote:
> 
>>>> The nice thing is reduction in half of the resulting binary size.
>>> 
>>> That's indeed nice! The unnecessarily huge size of binaries created
>>> with D / Optlink was in fact something hindering me to use D at all!
>> 
>> I'm sure that linker is doing it by writing compressed exe's. This means
>> that it has the same memory footprint, and it loads slower because it
>> must be decompressed. Also, if you store it in a zip file, the zip file
> 
> IMHO, that is a common misbelief when it comes to executable compressors. AFAIK, the time required for decompression is overcompensated by the time required to read less data from disk, even still nowadays.

True in general. But in the case of an executable file, how does it interacts with memory mapping in the virtual memory subsystem? If you need to actually load and decompress the whole executable upfront instead of relying on the virtual memory subsystem to load pages from disk as needed, it might very well increase your startup time. Also, if some parts of the executable needs to be paged out to disk because free physical memory is running low, this is almost free if the memory is directly mapped to a read-only file as the data is already on disk.

So there's certainly some scenarios where a compressed executable will fare better, but there's surely plenty others where it's the reverse.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-02-26 12:10, Sebastian Schuberth wrote:
> On 24.02.2011 19:41, Walter Bright wrote:
>
>>>> The nice thing is reduction in half of the resulting binary size.
>>>
>>> That's indeed nice! The unnecessarily huge size of binaries created
>>> with D / Optlink was in fact something hindering me to use D at all!
>>
>> I'm sure that linker is doing it by writing compressed exe's. This means
>> that it has the same memory footprint, and it loads slower because it
>> must be decompressed. Also, if you store it in a zip file, the zip file
>
> IMHO, that is a common misbelief when it comes to executable
> compressors. AFAIK, the time required for decompression is
> overcompensated by the time required to read less data from disk, even
> still nowadays.
>
>> won't be any smaller because recompressing compressed data doesn't make
>> it smaller.
>
> There really needs to be no compression or back magic involved to make
> the executable size for a simple program like
>
> ---8<---
>
> import std.stdio;
>
> void main(string[] args)
> {
> writeln("Hello World, Reloaded");
> }
>
> ---8<---
>
> smaller than the current 286 KiB! Some dead code elemination would
> already do, I guess.

On Mac OS X linking a Hello World application dynamically to Tango results in a 16Kb executable, the same size as for a Hello World written in C.

-- 
/Jacob Carlborg