Compiler: Size of generated executable file

retard re at tard.com.invalid
Tue Jan 12 01:40:11 PST 2010


Tue, 12 Jan 2010 02:45:08 +0000, dsimcha wrote:

> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>> It's actually a nice program. My point was that the era of tiny
>> executables has long since passed.
> 
> <rant>
> 
> 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?
> 
> </rant>

You could fit e.g. the whole Linux userspace application suite to disk 
cache or L1/2/3 cpu cache if they only were small enough. There is always 
a faster class of memory which would make the system faster, but with 
very strict space constraints.

In fact the good old command line programs work rather efficiently even 
today as they are usually 5 .. 150 kB large. They work quickly on a i586 
with 8 MB of RAM and they work lightning fast on my overclocked Core i7 
960. Unfortunately the same cannot be said about GUI applications. Even 
on the Core i7 machine with triple channel memory and two super fast ssd 
disks in raid-0, the startup and i/o response times are really shitty on 
the user friendliest GUI apps. If you have a rather mature program such 
as /bin/echo, you don't need to rewrite it each year. So why not write it 
in assembly once and just use it.



More information about the Digitalmars-d mailing list