Compiler: Size of generated executable file

[Roman Ivanov]

Nick Sabalausky Wrote:

> "retard" <re at tard.com.invalid> wrote in message 
> news:hihgbe$qtl$2 at digitalmars.com...
> > Mon, 11 Jan 2010 19:24:06 -0800, Walter Bright wrote:
> >
> >> 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.
> >
> > A 1 Tb spinning hard disk doesn't represent the current state-of-the-art.
> > I have Intel SSD disks are those are damn expensive if you e.g. start to
> > build a safe RAID 1+0 setup. Instead of 1000 GB the same price SSD comes
> > with 8..16 GB. Suddenly application size starts to matter. For instance,
> > my root partition seems to contain 9 GB worth of files and I've only
> > installed a quite minimal graphical Linux environment to write some
> > modern end-user applications.
> 
> Not that other OSes don't have their own forms for bloat, but from what I've 
> seen of linux, an enormus amout of the system is stored as raw text files. I 
> wouldn't be surprised if converting those to sensible (ie 
> non-over-engineered) binary formats, or even just storing them all in a 
> run-of-the-mill zip format would noticably cut down on that footprint.

Text files are easy to modify, extensible and self-describing. And you don't need custom tools to work with them. In most cases, if you made extensible binary configs, the space savings would be negligible.

Most lines in a typical config are of the form

some-key=some-vaue

If the value is ASCII text, like a file path, there simply isn't anything you could save by converting it to binary. If the value is a number, you would get some savings, but they would be negligible for anything but very large numbers. ( ceil(log_base_10(N)) - ceil(log_base_2(N))? Something of that sort.) You could get large savings on booleans, but you would have to be tricky, because memory still works in bytes.

You would get roughly the same savings by stripping text configs of comments and redundant whitespace.

Storing configs in zip files would increase boot and load times, because applications would waste cycles on unzipping them. That is bloat of a worse kind.