• Roman Ivanov <isroman-rem move.km.ru> Jan 13 2010
• "Nick Sabalausky" <a a.a> Jan 13 2010
• "Steven Schveighoffer" <schveiguy yahoo.com> Jan 14 2010

Roman Ivanov <isroman-rem move.km.ru> writes:

Nick Sabalausky Wrote:

 "retard" <re tard.com.invalid> wrote in message 
 news:hihgbe$qtl$2 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.

"Nick Sabalausky" <a a.a> writes:

"Roman Ivanov" <isroman-rem move.km.ru> wrote in message 
news:hilovb$ioc$1 digitalmars.com...
 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.


Good points. Although with binary, the key wouldn't necissarily need to be 
text. But yea, I'm probably just splitting hairs now.

 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.


I'm not sure that would be the case if the data was stored on a hard drive 
(as opposed to one of those flash drives), because wouldn't the cost of 
extra disk access typically be greater than decoding a non-top-of-the-line 
zip encoding? (Not that I really care all that much either way.) 

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 14 Jan 2010 00:19:56 -0500, Nick Sabalausky <a a.a> wrote:

 "Roman Ivanov" <isroman-rem move.km.ru> wrote in message
 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.


 I'm not sure that would be the case if the data was stored on a hard  
 drive
 (as opposed to one of those flash drives), because wouldn't the cost of
 extra disk access typically be greater than decoding a  
 non-top-of-the-line
 zip encoding? (Not that I really care all that much either way.)


Unless your text file is on the order of 200k bytes, you don't get much  
savings :)  hard drives read blocks, not bytes, so the relationship of  
load time to bytes is not linear.

-Steve