Compiler: Size of generated executable file

[Walter Bright]

dsimcha wrote:
> Vote++.  I'm convinced that there's just a subset of programmers out there that
> will not use any high-level programming model, no matter how much easier it makes
> life, unless they're convinced it has **zero** overhead compared to the crufty old
> C way.  Not negligible overhead, not practically insignificant overhead for their
> use case, not zero overhead in terms of whatever their most constrained resource
> is but nonzero overhead in terms of other resources, but zero overhead, period.
> 
> Then there are those who won't make any tradeoff in terms of safety,
> encapsulation, readability, modularity, maintainability, etc., even if it means
> their program runs 15x slower.  Why can't more programmers take a more pragmatic
> attitude towards efficiency (among other things)?  Yes, noone wants to just
> gratuitously squander massive resources, but is a few hundred kilobytes (fine,
> even a few megabytes, given how cheap bandwidth and storage are nowadays) larger
> binary really going to make or break your app, especially if you get it working
> faster and/or with less bugs than you would have using some cruftier, older, lower
> level language that produces smaller binaries?


I agree that a lot of the concerns are based on obsolete notions. First 
off, I just bought another terabyte drive for $90. The first hard drive 
I bought was $600 for 10Mb. A couple years earlier I used a 10Mb drive 
that cost $5000. If I look at what eats space on my lovely terabyte 
drive, it ain't executables. It's music and pictures. I'd be very 
surprised if I had a whole CD's worth of exe files.

Next, even a very large executable doesn't necessarily run any slower 
than a small one. The reason is the magic of demand paged virtual 
memory. Executables are NOT loaded into memory before running. They are 
memory-mapped in. Only code that is actually executed is EVER loaded 
into memory.

You can actually organize the layout of code in the exe file so that it 
loads very fast, by putting functions that call each other next to each 
other, and grouping rarely executed code elsewhere. Optlink has the 
features necessary to do this, and the -profile switch can output a file 
to drive Optlink to do the necessary layouts.

Other languages do appear to have smaller executables, but that's often 
because the runtime library is dynamically linked, not statically 
linked, and is not counted as part of the executable size even though it 
is loaded into memory to be run. D's runtime library is still statically 
linked in for the pragmatic reason that static linking avoids the "dll 
hell" versioning problem for your customers.

And lastly, it *is* possible to use D as a "C compiler" with the same 
overhead that C has. All you need to do is make your main a "C" main, 
and not link in Phobos. In fact, this is how I port dmd to new platforms 
before Phobos is built. Stick with "C" constructs (i.e. no dynamic 
arrays!) and it will work just like C does.