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