bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coreutils binary sizes over time


From: Alfred M. Szmidt
Subject: Re: Coreutils binary sizes over time
Date: Sun, 27 Jan 2008 11:23:54 +0100 (CET)

   Dr. David Alan Gilbert wrote on 27-01-08 01:29:
   > Hi,
   > 
   >   Out of a bit of boredom (and avoiding trying to fix a VHDL problem)
   > I decided to graph the sizes of a few of the binaries from coreutils,
   > as packaged by debian over time (I've included fileutils/shellutils).
   > 
   > At:
   > 
   > http://www.treblig.org/pics/debianbinarysizes.png
   > 
   > you can see a graph showing ls, du, df, true, and chmod
   > over about 10 years.
   > 
   > The raw data is here: http://www.treblig.org/data/debiansizes.csv
   > All of these are the Linux/x86 binary packages and all binaries
   > are ELF, stripped, with shared libs.
   > 
   > I've not made much attempt to analyse why things are growing;
   > although the fun one is the size of 'true' that used to be a tiny
   > shell script.
   > 
   > It's a bit scary that 'true' has gone from a 395 byte script to
   > a 22k binary in 10 years (even the first binary version I have is
   > under 5k); I can imagine that some of the other binaries probably
   > have more to do with system interaction (e.g. ls gaining selinux
   > support).
   > 
   > Dave
   > 

   Interesting.  It would be even more interesting if you'd mark the
   timestamps for breakthrough chipset and harddrive technology and
   anything that's driven by that (major POSIX changes, new filesystem
   types, threading [which in turn drive GCC for example] -- any more
   any one?) on that graph.

Would be interesting to see how normal hard drive sizes have grown in
that time as well.

But these graphs, while quite fun to watch, do not really provide much
information, gcc's output has changed alot over the years, and the
goal isn't to compile small binaries, but semi-fast ones, and that
will always lead to bloat (what functions get inlined, how gcc
compiles the same functions across versions, ...)

Even things how the binary format has changed is something that one
has to take into account, 10 years ago is a.out times, which had much
smaller binaries than ELF.


What is the drop at 900000000 epoch?  That one looks fun; I am
guessing it is the move to glibc 2.x?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]