Alternative linker win32/64

Michel Fortin michel.fortin at michelf.com
Sat Feb 26 07:01:43 PST 2011


On 2011-02-26 06:10:19 -0500, Sebastian Schuberth <sschuberth at 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 at michelf.com
http://michelf.com/



More information about the Digitalmars-d-announce mailing list