* Alfred M. Szmidt ([EMAIL PROTECTED]) wrote: > > Would be interesting to see how normal hard drive sizes have grown in > that time as well.
Of course hard drive growth is fast; but not everything is as fast; e.g. seek time and memory latency. > 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, ...) Indeed; still it seems wise to keep an eye on sizes just to make sure things aren't getting silly. > 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. Nod; these are all ELF. > What is the drop at 900000000 epoch? That one looks fun; I am > guessing it is the move to glibc 2.x? Yes, it appears to be - the first one is linked against libc.so.5 and an earlier dynamic linker I don't have. Going back to /bin/ls for a minute; using /usr/bin/time -a on /bin/ls /etc the number of minor page faults isn't actually as simple a story as the sizes: fu 3.16-5.3 253 fu 4.0 258 fu 4.1-10 289 cu 5.2.1-2 370 cu 5.97-5 400 cu 6.10-2 313 cu 6.10-2007 315 (Those correspond to the points on the graph, except the first one is missing since it is the libc 1.x version I can't easily run). Dave -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils