www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/10/09/08:07:21

From: "A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
To: DJGPP AT SUN DOT SOE DOT CLARKSON DOT EDU
Date: Mon, 9 Oct 1995 12:11:07 BST
Subject: Many small files versus big clusters

  "A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk> wrote (Subject: Lots of small
files in DJGPP waste space & should be chained up!):-
> The great size of the full DJGPP puts a big strain on people's hard disk
> stores. This is NOT helped by the current practice in many parts of it of
> having stuff on a mass of little files. ... new Pentiums whose hard disk
> clusters are 32K bytes each!! ...

  People suggested:-
> ... [try] e.g. stacker, drivespace or doublespace?
  I don't want to be hassled with those things. From what I have heard these
are troublesome to (go back to plain DOS file format from) if people don't
want them after all, and liable to interfere with things or to corrupt files
if the computer is switched off in mid process.

> Surely the disk could have been partitioned into 200- or 400-Mb logical
> drives, which would then have 2- or 4-Mb clusters?
  I don't want lots of little partitions so I don't know which logical drive
any given directory is in and each directory when wanting more space can only
get at its own partition's spare space and not other partitions' spare space.
Having 2 hard disks it is enough hassle remembering which of my stuff is on C:
and which is on D:.

> ... 1.2GB hard drives are running less than $250 these days, is it really
> that big a problem?
  But store space gets short in the end, I find.

> Having the sources for each function in a file for itself has its advantages
> also: one function linked into your program doesn't drag in all the others.
> ... whenever a compilation unit is used the whole unit is linked in. ... not
> enough information in the .o and .obj formats to do better.

  If (say) all the files LIBSRC\C\IO\*.C are chained into one big file
LIBSRC\C\IO.C, and after each function (plus its associated outermost-level
declarations) you insert a new preprocessor command `#libunit', then the
preprocessor could tell the compiler to tell the assembler to set up the *.O
file in such a way that if the *.O is assembled into a library file each (part
separated by `#libunit' lines) becomes a separate compilation unit in the
library file. This would involve minor alterations to the preprocessor and
compiler and assembler and linker, but in my opinion would be worth it. Even
with 4096-byte clusters a lot of space is wasted at the ends of clusters. When
someone is looking at his last few meg free hard disk space and is desperately
wondering what to delete, he very much needs a few big files rather than a lot
of small files. Please consider this.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019